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1 Scope 

The present document specifies IPCablecom, (also referred to as PacketCable) multimedia services over DOCSIS. 



1.1 Purpose 



The intent of the present document is to support the deployment of general Multimedia services by providing a 
technical definition of several IP -based signalling interfaces that leverage core QoS and policy management capabilities 
native to DOCSIS Versions 1 . 1 and greater. Throughout the present document, the term DOCSIS will be used to refer 
to any DOCSIS version greater than or equal to 1.1. For the purposes of the present document, Multimedia services may 
be defined as IP -based services (e.g. online gaming, video-conferencing, streaming media, etc.) requiring QoS-based 
network resources (as contrasted with services such as web browsing, e-mail, instant messaging and file-sharing that are 
commonly provided using best-effort flows). While telephony or voice-based services are not specifically excluded 
from this definition, the IPCablecom 1 .x set of specifications provide coverage specific to this type of service delivery, 
and, therefore, those specifications should be consulted as appropriate. 

IPCablecom Multimedia defines a service delivery framework that provides general-purpose QoS, event-based 
accounting, and security functionality founded upon the mechanisms defined in IPCablecom 1 .x. However, due to the 
broader spectrum of applications and services addressed by this initiative, each of these functional areas has been 
revisited and generalized for the present purposes. Telephony-specific requirements and interfaces (e.g. call signalling, 
PSTN interconnection and electronic surveillance) are not part of IPCablecom Multimedia, while core functionality 
such as QoS resource management mechanisms, has been enhanced. Throughout this process, one of the primary 
objectives of this work has been to leverage and reuse as much of the existing body of IPCablecom 1.x investment, 
knowledge base, and technical functionality as possible. 

Key features of the described Multimedia service delivery framework include: 



• 



Simple, powerful access to DOCSIS QoS mechanisms supporting both time and volume-based network 
resource authorizations. 

• Abstract, event-based network resource auditing and management mechanisms. 

• A robust security infrastructure that provides integrity and appropriate levels of protection across all interfaces. 

As outlined in the technical report [15], the current scope of the present document is limited to network-based QoS 
resource management and usage auditing capabilities. This approach was motivated by several criteria, including rapid 
time-to-market for QoS-enhanced Multimedia services (which may take the form of new applications or existing 
applications retrofitted per the present document), the absence of QoS signalling requirements on CPE devices, and 
security assurances provided by an absence of client-based QoS signalling. 

In addition, the QoS signalling mechanisms outlined herein provide the foundation for client-based QoS signalling 
mechanisms which may be defined in the future. As such scenarios have already been considered and documented in 
the technical report, one of the secondary goals of the present document is to provide for smooth migration to a client- 
based model as market and technology advances dictate. It should also be noted that the scope of the QoS framework 
defined in the present document is limited to the access network and that the choice of specific backbone QoS strategies 
is left as an administrative decision to be addressed by each service provider as it deems best. 

1 .2 Relation to IPCablecom 1 .x 

Since its inception the IPCablecom initiative has been positioned as an IP-based Multimedia service deployment 
infrastructure, exploiting and enhancing the underlying QoS capabilities of the DOCSIS access network. Based on 
market demand and technology readiness, VoIP was chosen as the first IP-based service to leverage these unique 
broadband access network capabilities, as the IPCablecom 1.x suite of specifications simultaneously defines both a 
general QoS-based service delivery framework and a number of telephony-specific functional elements and 
mechanisms. 
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Specifically, the IPCablecom 1 .x VoIP architecture provides specifications promoting multi-vendor interoperability and 
CableLabs certification and qualification in the following key telephony areas: 

Network-based call signalUng (NCS) 

Inter-domain call signalling (CMSS) 

PSTN gateway and interop functionality (TGCP, ISTP) 

Access-network and backbone QoS capabilities (DQoS, IQoS) 

Event messaging with telephony-specific extensions (EM) 

CPE endpoint provisioning and monitoring (Provisioning and SNMP MIBs) 

Comprehensive suite of interface security mechanisms (Security) 

Primary-line telephony characteristics 

Electronic surveillance 

Since the intent of the present document is to extract the functional core of this architecture in support of the 
enhancement and deployment of other Multimedia services, support for these telephony-specific features is not 
required, while the core QoS, event messaging and security mechanisms are emphasized and generalized. The result is a 
framework that provides IP -based access to DOCSIS access-network QoS mechanisms complemented by secure and 
robust authorization and audit mechanisms. 

In keeping with the IPCablecom 1.x Dynamic Quality of Service (DQoS) model, the primary logical construct in 
support of QoS-based service delivery is a Gate (along with its accompanying authorization token). An IPCablecom 
Gate represents a policy-based authorization for a specific envelope of network resources characterized by a suite of 
QoS parameters, as well as classifiers for originating and terminating IP addresses and ports, which define and limit the 
scope of the associated QoS -enhanced flow. 

IPCablecom 1.x defines a pre-authorization model in which Gates are created and installed at policy enforcement points 
(e.g. a CMTS) prior to actual network resource reservation or activation requests. This process, termed Gate Control, is 
managed through a COPS-based policy interface on the CMTS. In the present document, this interface is generalized 
and enhanced to allow for full lifecycle management of QoS-based service flows through this policy interface. That is. 
Gate installation and management is supplemented with service flow creation, modification and deletion functions to 
provide for network-based QoS service delivery. 

To complement these enhanced QoS policy and signalling capabilities, the RADIUS -based event messaging 
infrastructure of IPCablecom 1.x is carried over, but with telephony-specific primitives tagged as optional. Since the 
EM protocol was designed with a considerable amount of generality and abstraction, this approach provides continuity 
with existing protocol and Record Keeping Server (RKS) implementation while still allowing Multimedia vendors to 
select from a set of supplementary protocol primitives on an as-needed basis. For example, if a QoS-based video 
conferencing service were being developed based on the present document, a number of telephony-specific EM 
message types (e.g. Call_Answer and Call_Disconnect) may map directly to the service's audit requirements. 

Finally, in order to provide robust security for this Multimedia framework, IPsec will be applied to the COPS and 
RADIUS interfaces in a manner analogous to the corresponding interfaces in the IPCablecom 1.x architecture. 



References 
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NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
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2.1 Normative references 



The following referenced documents are necessary for the application of the present document. 

[I] ETSI TS 102 639-4: "Access and Terminals, Transmission and Multiplexing (ATTM); Third 
Generation Transmission Systems for Interactive Cable Television Services - IP Cable Modems; 
Part 4: MAC and Upper Layer Protocols [ITU-T Recommendation J.222.2 (07/2007), modified]". 

[2] IETF RFC 1305 (March 1992): "Network Time Protocol (Version 3) Specification, 

Implementation and Analysis". 

[3] IETF RFC 2205 (September 1997): "Resource ReSerVation Protocol (RSVP) - Version 1 

Functional Specification". 

[4] IETF RFC 2210 (September 1997): "The Use of RSVP with IETF Integrated Services". 

[5] IETF RFC 221 1 (September 1997): "Specification of the Controlled-Load Network Element 

Service". 

[6] IETF RFC 2212 (September 1997): "Specification of Guaranteed QuaHty of Service". 

[7] IETF RFC 2474 (December 1998): "Definition of the Differentiated Services Field (DS Field) in 

the IPv4 and IPv6 Headers". 

[8] IETF RFC 4546: "Radio Frequency (RF) Interface Management Information Base for Data over 

Cable Service Interface Specifications (DOCSIS) 2.0 Compliant RF Interfaces". 

[9] IETF RFC 2748 (January 2000): "The COPS (Common Open Policy Service) Protocol". 

[10] IETF RFC 2753 (January 2000): "A Framework for PoUcy-based Admission Control". 

[II] IETF RFC 2866 (June 2000): "RADIUS Accounting". 

[12] IETF RFC 3084 (March 2001): "COPS Usage for Policy Provisioning (COPS-PR)". 

[13] ITU-T Recommendation J. 163 (12/2007): "Dynamic quality of service for the provision of 

real-time services over cable television networks using cable modems". 

[14] ITU-T Recommendation J. 164 (12/2007): "Event message requirements for the support of 

real-time services over cable television networks using cable modems". 

[15] PKT-TR-MM-ARCH-V03-091029: PacketCable TM Technical Report "Multimedia Architecture 

Framework", Cable Television Laboratories, Inc. 

NOTE: Available at http://cablelabs.com/specifications/PKT-TR-MM-ARCH-V03-091029.pdf 

[16] ITU-T Recommendation J. 170 (1 1/2005): "IPCablecom security specification". 

[17] ETSI ES 201 488-3 (Vl.2.2): "Access and Terminals (AT); Data Over Cable Systems; 

Part 3: Baseline Privacy Plus Interface Specification". 

[18] IETF RFC 2865: "Remote Authentication Dial In User Service (RADIUS)". 

[19] IEEE 802.1D-1998: "IEEE Standard for Local Ai-ea Network MAC (Media Access Control) 

Bridges". 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i. 1 ] IETF RFC 275 1 (January 2000): "Signaled Preemption Priority Policy Element" . 

[i.2] SCTE 159-2 2010: "Multimedia Apphcation and Service Part 2: IPCablecom Multimedia Web 

Services". 
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[i.3] IETF RFC 3 168 (September 2001): "The Addition of Explicit Congestion Notification (ECN) to 

IP". 

[i.4] IETF RFC 3171 (August 2001): "lANA Guidelines for IPv4 Multicast Address Assignment". 

[i.5] IETF RFC 4291 (February 2006): "IP Version 6 Addressing Architecture". 

[i.6] IETF RFC 791: "Internet Protocol". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Application Manager (AM): system that interfaces to Policy Server(s) for requesting QoS-based service on behalf of 
an end-user or network management system 

cable modem: layer two termination device that terminates the customer end of an IP Cable Modem System 

Client Type 1: represents existing "legacy" endpoints (e.g. PC applications, gaming consoles) which lack specific QoS 
awareness or signalling capabilities 

NOTE: This Client knows nothing about Cable Modem, or IPCablecom messaging, and hence no related 
requirements can be placed upon it. Such clients may range from simple analog audio and video 
presentation devices to complex networked peripherals and consumer electronics, such as set-top boxes or 
gaming consoles. This Client communicates with an Application Manager to request service, and does not 
request QoS resources directly from the operator access network. The present document supports only 
client type 1 . 

Client Type 2: similar to an IPCablecom-T telephony MTA in that it supports QoS signalling based on IPCablecom 
DQoS 

NOTE: This Client is aware of IPCablecom Multimedia QoS, and communicates with an Application Manager to 
request service and obtain a token for access-network resources. The client then presents this token when 
requesting QoS resources from the access network (pkt-mm-1, pkt-mm-6). 

Client Type 3: requests QoS based on RSVP without Application Manager interaction 

NOTE: This Client is aware of IETF standards-based RSVP and uses this protocol to request QoS resources from 
the access network directly from the CMTS. 

DOCSIS: describes a specific cable modem technology 

IPCablecom: ETSI deliverables including an architecture and a series of specifications that enable the delivery of real 
time services (such as telephony) over the cable television networks using cable modems 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AM Application Manager 

ACK Acknowledge 

AS Application Server 

BCID BiHing Correlation ID 

NOTE: Defined in the IPCablecom Event Messaging specification. 

CM Cable Modem 

CMS Call Management Server 

CMSS Call Management Server Signalling 
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CMTS 
COPS 



Cable Modem Termination System 
Common Open Policy Service 



NOTE: Defined in RFC 2748 [9] . 

DEC Decision 

DQoS Dynamic Quality of Service 

DSA Dynamic Service Add 

DSC Dynamic Service Change 

DSD Dynamic Service Delete 

EM Event Message 

FQDN Fully Qualified Domain Name 

IETF Internet Engineering Task Force 

IP Internet Protocol 

ISTP Internet Signalling Transport Protocol 

MGC Media Gateway Controller 

MIB Management Information Base 

MTA Multimedia Terminal Adapter 

NAT Network Address Translation 

NCS Network-based Call Signalling 

PDP Policy Decision Point 

NOTE: Defined in RFC 2753 [10]. 

PEP Policy Enforcement Point 

NOTE: Defined in RFC 2753 [10]. 

PS Policy Server 

PSTN Public Switch Telephone Network 

QoS Quality of Service 

RADIUS Remote Authentication Dial-In User Service 

NOTE: Defined in RFC 2865 [18] and RFC 2866 [11]. 

RAP Resource Allocation Protocol 

NOTE: Working Group in the IETF responsible for the definition and maintenance of the COPS protocol. 

RCD Resource Control Domain 

REQ Request 

RFC Request for Comments 

NOTE: Technical policy documents approved by the IETF which are available at http://www.ietf org/rf c . html . 

RFI Radio Frequency Interface 

NOTE: Specification defining MAC and Physical layer interfaces between CMTS and CM network elements. 

RKS Record Keeping Server 

RSP Response 

RSVP Resource Reservation Protocol 

NOTE: Defined in RFC 2205 [3] . 

SCD Session Control Domain 

TCP Transmission Control Protocol 

TGCP Trunking Gateway Control Protocol 

TLV Type-Length-Value 

NOTE: Technique used in formatting protocol elements. 

UDP User Datagram Protocol 

NOTE: A connectionless protocol built upon Internet Protocol (IP). 
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UGS Unsolicited Grant Service 

NOTE: DOCSIS RFI Annex B QoS scheduling type used for constant bit rate services (e.g. voice codecs). 

UGS/AD Unsolicited Grant Service with Activity Detection 

VoIP Voice over IP 

VPN Virtual Private Network 



Void 



Technical Overview 



This clause consists of background material which some readers may find to be useful context for the detailed protocol 
interface specifications that follow. The intent in this clause is to provide a high-level overview of the IPCablecom 
Multimedia architecture and the fundamental technologies upon which it is based. 



5.1 QoS Background 



As noted throughout the present document, one of the primary features of the IPCablecom Multimedia service 
framework lies in the fact that it provides IP-layer access to sophisticated QoS capabilities defined in DOCSIS 
versions 1 . 1 and greater and IPCablecom 1 .x. This clause provides a brief overview of these capabilities as preparatory 
background for the detailed QoS policy and resource management discussion that follows. 



5.1.1 DOCSIS QoS Summary 



The DOCSIS 3.0 MAC and Upper Layer Protocols Interface Specification [1] defines a set of QoS facilities based on a 
fundamental network resource management construct known as a Service Flow. A Service Flow is defined as "a 
MAC-layer transport service which (1) provides unidirectional transport of packets from the upper layer service entity 
to the RF, and (2) shapes, polices, and prioritizes traffic according to QoS traffic parameters defined for the flow." In 
addition to this primary abstraction facilitating the reservation and scheduling of shared access network resources on a 
per-flow basis, a number of tangible supporting constructs are defined and used to manage these resources. Three of 
these are: 

• Service Flow Encodings: type-length-value (TLV) encoded parameters used to define QoS parameters 
associated with a Service Flow. 

• Classifier: type-length-value (TLV) encoded IP, Ethernet and IEEE 802. ID [19]/q parameters used to define 
and limit the scope of a flow in terms of originating and terminating endpoints. 

• Payload Header Suppression Rules: type-length-value (TLV) encoded parameters used by the sending entity to 
suppress repetitive payload headers following the DOCSIS Extended Header field and used by the receiving 
entity to restore the suppressed header information. IPCablecom Multimedia does not support this 
functionality at this time. 

While DOCSIS supports provisioned (i.e. static, long-lived Service Flows that are established during the CM 
registration process) and dynamic (i.e. transient Service Flows that are added, modified and deleted on an as-needed 
basis) QoS models, the IPCablecom Multimedia framework is primarily concerned with the dynamic variety as this 
allows for optimal network resource management through statistical multiplexing as service requirements demand. 

Service Flow management is performed through MAC-layer DOCSIS Dynamic Service Add/Change/Delete 
(DSA/DSC/DSD) messaging, which may be initiated either by the CM or by the CMTS. DSA and DSC transactions 
take the form of a three-way exchange in which a request (REQ) is followed by a response (RSP) which is then 
acknowledged (ACK). DSD messages are simple two-way exchanges. A specific attribute known as a Confirmation 
Code is provided in each DSx response message and indicates the success or failure status of a transaction. 
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One important point to note in reviewing the QoS capabilities provided in DOCSIS is that upstream and downstream 
Service Flows receive fundamentally different treatment at the CMTS. This is a result of the fact that upstream RF 
channels are contentious, shared-access mediums, taking the topological form of a many-to-one relationship between 
multiple CMs and a single CMTS. Conversely, the downstream RF channel behaves much more akin to a traditional IP 
router in which packets arrive (either from the access network or over backbone trunks), are queued, and are forwarded 
to one or more destinations. Consequently, distinct QoS mechanisms are applied depending upon whether a particular 
uni-directional Service Flow is oriented in the upstream or downstream direction. 

Upstream Service Flows may be defined with one of five service flow scheduling types: 

• Best-Effort: a standard contention-based resource management strategy in which transmit opportunities are 
granted on a first-come-first-served basis, albeit under the coordination of the CMTS scheduler. This 
scheduling type may be supplemented with QoS characteristics in which, for example, maximum rate limits 
are applied to a particular Service Flow. 

• Non-Real-Time Polling: a reservation-based resource management strategy in which a particular CM is polled 
on a fixed interval to determine whether data has been queued for transmission on a particular service flow, 
and, if so, a transmission opportunity or grant for that service flow is provided by the scheduler. 

• Real-Time Polling: analogous to the Non-Real-Time-Polling scheduling type, except that the fixed polling 
interval is typically very short (< 500 ms). Polling scheduling types are most suitable for variable- bit-rate 
traffic that has inflexible latency and throughput requirements. 

• Unsolicited Grant: a reservation-based resource management strategy in which a fixed-size grant is provided to 
a particular Service Flow at (nearly) fixed intervals without additional polling or interaction. This scheduling 
type is most suitable for constant bit-rate traffic and eliminates much of the protocol overhead associated with 
the polling types. 

• Unsolicited Grant with Activity Detection: a reservation-based resource management strategy that represents a 
hybrid of the polling and unsolicited grant scheduling types in which fixed grants are provided at (nearly) 
fixed intervals so long as data is queued for transmission. During periods of inactivity, this scheduling type 
reverts to a polling mode in order to conserve unused bandwidth. 

Due to the unique nature and specialized characteristics of each of these scheduling types, specific QoS parameters are 
associated with each. These parameters are outlined in detail in the clause that follows. 

Downstream Service Flows are defined using the same set of QoS parameters that are associated with the Best-Effort 
scheduling type on the upstream. 

Regardless of the orientation of the flow or the particular scheduling type requested, all dynamic Service Flows 
procedure through three logical states, summarized below. While certain optimized signalling scenarios allow for a 
so-called "single-phase" commit operation, the request still proceeds logically through all three phases as it is serviced 
at the CMTS. 

• Authorized: requests are authenticated and network policy rules are applied resulting in an authorization 
envelop forming the boundary of subsequent reservation requests. 

• Admitted (or Reserved): an inactive Service Flow is constructed and resources are reserved by the scheduler so 
that subsequent activation requests are guaranteed to succeed; reserved resources may be used by best-effort 
traffic (from the same or different CMs) until committed. 

• Active (or Committed): the Service Flow is activated, along with corresponding Classifiers; QoS-enhanced 
packets are now able to traverse the flow. 

NOTE: In a literal sense, DOCSIS does not define "states", but, rather, "attributes" of Service Flows which are 

completely replaced with each DSC transaction. The states described here are a logical construct used in a 
conceptual model describing the resource management process performed on the CMTS. Also, the 
DOCSIS RFI specification standardizes upon the terms "admitted" and "active" in defining the attributes 
of a service flow, while IPCablecom has adopted the equivalent terms "reserved" and "committed" in 
characterizing Gate states. 
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While DOCSIS does not define a specific authorization procedure to be applied to DSx messages, it does provide 
protocol support through a facility known as an Authorization Block for service-specific authorization schemes. Any 
credentials or authorization tokens that are presented via the Authorization Block are forwarded to an appropriate 
authorization module prior to the processing of the DSx request on the CMTS. IPCablecom makes extensive use of this 
authorization mechanism as described below. 

5.1 .1 .1 DOCSIS 3.0 Multicast QoS Framework 

In DOCSIS 3.0, a framework was developed for providing special QoS treatment for IP Multicast Sessions that were 
signalled via IP Multicast protocols such as IGMP and MLD. This framework relies on an incoming membership 
request or "JoinMulticastSession" to be evaluated against the CmtsGroupConfig table for the purposes of determining if 
special QoS handling needed for a specific multicast session. 

The present document allows a Gate-Set message be treated as the functional equivalent of a "JoinMulticastSession". 
The present document replaces the use of the configured CmtsGroupConfigTable with dynamic IPCablecom 
Multimedia based Gate-Set messages for configuring the QoS of IP multicast replications to subscribers. Multicast 
Gates are expected to use application level encryption as IPCablecom Multimedia does not define encryption of IP 
multicast flows. Furthermore for Multicast Gates, IPCablecom Multimedia overrides the use of the IP Multicast Join 
Authorization feature defined in [1]. 

Addition of non-IPCablecom Multimedia signalled IP Multicast Joiners to an existing IPCablecom Multimedia-initiated 
Group Service Flow (GSF) [1] is beyond the scope of the present document. The combination of non-IPCablecom 
Multimedia signalled IP Multicast Joiners and IPCablecom Multimedia-initiated Multicast joiners onto the same GSF is 
handled in a vendor specific manner. 

An operator should configure the IP Multicast Join Authorization feature to reject unauthorized attempts by 
non-IPCablecom Multimedia authorized Multicast Joins to join multicast sessions intended to be authorized only by 
IPCablecom Multimedia. 

IPCablecom Multimedia Multicast Gates are implemented using DOCSIS Single-Session Group Service Flows. 

The operation of IPCablecom Multimedia Multicast Gates for subscribers reached through pre-3.0 CMs is beyond the 
scope of the present document. 

5.1 .2 IPCablecom 1 .x QoS Summary 

While the DOCSIS 3.0 MAC and Upper Layer Protocols Interface [1] specification defines the fundamental QoS 
mechanisms that form the core of the IPCablecom DQoS model, the IPCablecom DQoS specification [13] augments 
these capabilities with a COPS-based policy management framework. Just as the Service Flow represents the primary 
abstraction in the DOCSIS QoS model, the Gate plays a comparably significant role in the IPCablecom DQoS scheme. 
A Gate defines a resource authorization envelope consisting of IP -level QoS parameters as well as classifiers defining 
the scope of Service Flows that may be established against the Gate. In accordance with the DOCSIS authorization 
mechanisms described above, only DSx requests which conform to the following general relation on a parameter-by- 
parameter basis will be granted: 

Authorized Envelope > Reserved Envelope > Committed Envelope 

Based in this policy management model, IPCablecom 1 .x defines a pre-authorization scheme in which network 
resources are authorized in advance of DSx messaging that requests establishment of a corresponding Service Flow. 
Consequently, the COPS interface used to install and manage Gates corresponds more closely with the COPS -PR model 
defined in RFC 3084 [12] than with the standard COPS scheme specified in RFC 2748 [9]. Also, in order to install and 
manage these Gates, the IPCablecom DQoS specification defines a set of COPS client-specific objects which constitute 
the primitives of a Gate Control signalling interface between the CMS and the CMTS. 

Specifically, the CMS may be logically decomposed into a Call Agent, responsible for telephony call-state 
maintenance, and a Gate Controller, which receives authorization requests from the Call Agent (through an internal 
interface) and installs policy decisions in the form of Gates on the CMTS. In the IPCablecom Multimedia model, this 
decomposition is formalized through two separate network elements, the Policy Server (analogous to the IPCablecom 
1 .X Gate Controller) and the Application Manager (defining service-specific functionality similar to the Call Agent in 
the IPCablecom 1.x model). 
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As an illustration of this pre-authorization model and the use of the Gate Control interface on the CMTS, a typical 
single-zone (i.e. using a single CMS) on-net IPCablecom 1.x call flow proceeds as follows (some of these steps would 
normally happen in parallel): 

E-MTAp boots, provisions and registers with CMS 

CMS issues request to E-MTA^ for notification of off-hook event and dialled-digits 

E-MTAj boots, provisions and registers with CMS 

CMS issues request to E-MTAj for notification of off -hook event and dialled-digits 

E-MTAp goes off-hook, notifies CMS and delivers dialled-digits 

CMS issues a request to E-MTA^ to create a new logical connection and retrieves SBP^ 

CMS issues a request to E-MTAj to create a new logical connection and retrieves SDPj 

CMS installs a Gate on CMTS^ and retrieves corresponding GatelD^ token 

CMS installs a Gate on CMTSj and retrieves corresponding GatelD^ token 

CMS issues a request (with GatelD^) to E-MTA^ to reserve resources and play ringback 

E-MTAp issues a DSA-REQ to CMTS^ to establish service flows and reserve resources 

CMS issues a request (with GatelD^) to E-MTAj to reserve resources and play an alerting tone 

E-MTAj issues a DSA-REQ to CMTSj to establish service flows and reserve resources 

E-MTA( goes off -hook and notifies CMS 

CMS issues a request to E-MTA^ to stop playing ringback, commit resources and cut-through media path 

E-MTAq issues a DSC-REQ to CMTS,, to commit resources 

CMS issues a request to E-MTA( to commit resources and cut-through media path 

E-MTA( issues a DSC-REQ to CMTSf to commit resources 

Call proceeds 

In contrast to the IPCablecom 1.x model in which the client device (i.e. E-MTA) initiates the resource reservation and 
activation procedures, the IPCablecom Multimedia resource management model allows for the proxying of these steps 
on behalf of the endpoint through an enhanced Gate Control interface. 

This concludes this brief review of DOCSIS and IPCablecom 1.x QoS fundamentals. For further details related to either 
of these considerably complex topics, please consult the respective primary sources [1] and [13]. The next clause 
provides a summary overview of the IPCablecom Multimedia architecture including each of the primary network 
elements and associated interfaces as further preparation for the technical protocol specification that follows. 

5.2 Architecture 

The IPCablecom Multimedia technical report [15] describes an architecture framework and reference model for 
IPCablecom Multimedia. The present document applies the model contained in the architectural framework and adds 
normative requirements to provide a scalable, interoperable solution suitable for deploying IPCablecom Multimedia 
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5.2.1 Client Types 

The IPCablecom Multimedia tech report defines three kinds of client types: 

• Client Type 1, which represents existing "legacy" endpoints (e.g. PC applications, gaming consoles) that lack 
specific QoS awareness or signalling capabilities. This client has no awareness of DOCSIS, CableHome, or 
IPCablecom messaging, and hence no related requirements can be placed upon it. Client Type 1 communicates 
with an Application Manager to request service, and does not (cannot) request QoS resources directly from the 
cable operator access network. 

• Client Type 2 is similar to an IPCablecom 1.x telephony MTA in that it supports QoS signalling based on the 
IPCablecom DQoS specification [13]. 

• Client Type 3 directly requests QoS treatment from the access network without Application Manager 
interaction. This client is aware of IETF standards-based RSVP and uses this protocol to request access 
network QoS resources directly from the CMTS. 

In the current release of the present document support is limited to Client Type 1 . Consequently, this release of the 
present document supports only Scenario 1, the "Proxied QoS with Policy Push" scenario, described in [15]. Under this 
scenario, the Application Manager is responsible for requesting QoS resources on behalf of the client, and a Policy 
Server pushes the request down to the CMTS, which is the device actually responsible for setting up and managing the 
DOCSIS service flows required by the application. 

5.2.2 IPCablecom Multimedia Devices 

In addition to the client (which typically resides at a subscriber's premises), IPCablecom Multimedia requires several 
network elements residing in, or accessible to and trusted by, the cable operator's network. In the process of describing 
these network elements throughout the present document we borrow heavily from standard IETF terminology and 
concepts. For a more thorough treatment of the overall IPCablecom Multimedia architecture, including a discussion of 
underlying requirements and objectives, please refer to the technical report [15]. 

Since COPS [9] and COPS-PR [12] each use the terms Policy Enforcement Point (PEP) and Policy Decision Point 
(PDP) in substantially different interaction scenarios and since IPCablecom Multimedia adds further nuances to these 
concepts (particularly in the definition of the Policy Server), it is occasionally confusing to think solely in terms of 
PEPs and PDPs to understand the responsibilities of the various components of the IPCablecom Multimedia 
architecture. To attempt to alleviate this confusion, portions of the present document employ the notion of a Service 
Control Domain and a Resource Control Domain to draw distinctions in the type of policy that is being defined and 
enforced. 

The Resource Control Domain (RCD) may be defined as a logical grouping of elements that provide connectivity and 
network resource level policy management along the packet forwarding paths to and from an end host. The RCD 
consists of CMTS and Policy Server entities whose responsibilities include management of resources along the packet 
forwarding paths. 

The Service Control Domain (SCD) is defined as a logical grouping of elements that offer applications and content to 
service subscribers. The Application Manager resides in the SCD. Note that there may be one or more SCDs related to a 
single RCD. Conversely, each RCD may interact with one or more SCDs. 
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Figure 1 : Session and Resource Control Domains 

In the IPCablecom Multimedia architecture the fundamental role of the Application Server is to process requests on 
behalf of clients for network services and to convert them into session requests. The session request is then forwarded to 
the Application Manager for additional Service Control Domain processing. 

In the IPCablecom Multimedia architecture the fundamental role of the Application Manager is to maintain an 
application's session-level state and to enforce any SCD policies against client-driven session requests either directly 
from the client or via the Application Server. If the client's session requests pass the Application Manager's SCD policy 
checks, the Application Manager converts the session request into a resource request and passes it on to the Policy 
Server for Resource Control Domain (RCD) policy checks. If the resource request fails the RCD policy check the 
Policy Server denies the resource request and the Application Manager consequently denies the client's session request. 
If, however, the resource request passes the Policy Server's RCD checks, the Policy Server forwards the request on to 
the CMTS for network-level admission control. 

Fundamentally, the roles of the various IPCablecom Multimedia components are: 

• The Application Server is responsible for relaying client requests to the Application Manager. 

• The Application Manager is responsible for application or session-level state and for applying SCD policy. 

• The Policy Server is responsible for applying RCD policy and for managing relationships between Application 
Managers and CMTSs. 

• The CMTS is responsible for performing admission control and managing network resources through DOCSIS 
Service Flows. 

It may be useful here to clarify our use of the terms "admission control" and "policy authorization". For the purposes of 
the present document admission control is generally understood as the process of managing a finite pool of network- 
level resources (e.g. access network bandwidth, scheduler DOCSIS minislots, or CMTS resources supporting Gates and 
timers, etc.) and admitting requests against this pool. For performance reasons admission control is usually performed 
directly on network elements managing the packet forwarding path (such as the CMTS), though some sophisticated 
Policy Server implementations may choose to maintain state associated with network resources, thus supplementing and 
contributing to the admission control process. 

In contrast, policy authorization is used here to describe higher-level aggregate usage policies (e.g. number of 
concurrent authorizations for a particular subscriber or service) which constitute a cable operator's network management 
strategy. Policy authorization is almost always defined and enforced at the Policy Server. 

The rest of this clause describes each of these architectural components and their associated interfaces in more detail. 
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5.2.2.1 Application Server (AS) 



The Application Server is a network entity that interfaces with the Apphcation Manager that requests IPCablecom 
Multimedia services on behalf of clients. The AS may reside on the cable operator's network or it may reside outside of 
this domain and interact with the cable operator network via a particular trust relationship. Similarly, the AS may be 
under direct control of the operator or it may be controlled by a third-party. Any given AS may communicate with one 
or more Application Managers. 

The AS will communicate with a client via a signalling protocol that is outside the scope of the present document. 
Using this unspecified protocol, the AS authenticates and authorizes client requests based upon Service Control Domain 
policies. For client requests that pass these checks, the AS determines the particular QoS parameters necessary to 
deliver the service to the client, based upon its knowledge of the requested service. It then sends a request for these 
resources to the appropriate Application Manager, which may deny the request based upon additional Service Control 
Domain policies or may pass the request on to the Policy Server. 

5.2.2.2 Application Manager (AM) 

As noted in the preceding summary, the Application Manager is a network entity that defines SCD policies, coordinates 
subscriber-initiated requests for application sessions with access to the resources needed to meet those requests, and 
maintains application-level state. 

The AM may reside on the cable operator's network or it may reside outside this domain and interact with the cable 
operator network via a particular trust relationship (typically defined by and enforced on the basis of a Service Level 
Agreement). Similarly, the AM may be under the direct control of the operator or it may be controlled by a third party. 
Any given Application Manager may communicate with one or more Policy Servers on the operator's network; 
likewise, one or more Application Managers may communicate with any given Policy Server on the operator's network 
(so long as an appropriate trust relationship exists). 

The Application Manager may communicate with the Application Server using a signalling protocol as defined in [i.2]. 
For Application Server requests the AM authenticates and authorizes the Application Server requests based upon 
Service Control Domain policies. 

The Application Manager may communicate with a client via a signalling protocol that is beyond the scope of the 
present document. Using this unspecified protocol, the AM authenticates and authorizes client requests based on 
Service Control Domain policies. 

For client and Application Server requests that pass these checks, the AM determines the particular QoS parameters 
necessary to deliver the service to the client, based on its knowledge of the requested service. It then sends a request for 
these resources to the appropriate Policy Server, which may deny the request based on network or RCD policy or may 
pass the request on to the CMTS for admission control and enforcement. 

5.2.2.3 Policy Server (PS) 

As discussed in RFC 2753 [10], the policy management framework underlying IPCablecom Multimedia is based on the 
work of the lETF's Resource Allocation Protocol (RAP) working group. Since the Policy Server is situated between the 
Application Manager and the CMTS, it simultaneously plays a dual role as a "proxy" for AM-initiated session requests 
and as a "sentry" for defining and enforcing Resource Control Domain policy. 

As described in [10] and in keeping with the IPCablecom 1.x DQoS model, the Policy Server serves as Policy Decision 
Point (PDP) in relation to the CMTS in that the Policy Server implements cable operator-defined authorization and 
resource-management procedures. Conversely, the Policy Server assumes the role of Policy Enforcement Point (PEP) in 
relation to the Application Manager as it proxies Gate Control messages to and from the CMTS element. 

To revisit the interaction scenario, the Application Manager issues policy requests to the Policy Server. The Policy 
Server acting as a "sentry" for these requests, and applies a set of policy rules that have been pre-provisioned by the 
cable operator. Upon passing the checks, the Policy Server then acts as a "proxy" with respect to the Application 
Manager and the CMTS, forwarding the policy request and returning any associated response. Each policy request 
transaction must be processed individually. 

Policy decisions may be based on a number of factors, such as: 

• Parameters associated with the request and the status of available resources 
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• Identity of the particular client and associated profile information 

• Application parameters 

• Security considerations 

• Time-of-day 

The primary functions of the Policy Server include: 

• A policy decision request mechanism, invoked by Application Managers 

• A policy decision request "policing" mechanism, enforcing installed Policy Rules 

• A policy decision delivery mechanism, used to install policy decisions on the CMTS 

• A mechanism to allow for the proxying of QoS management messages to the CMTS on behalf of the 
Application Manager 

• An event recording interface to a Record Keeping Server that is used to log policy requests, which may in turn 
be correlated with network resource usage records 

Since the Policy Server functions as a proxy between the AM and CMTS elements (with complementary client and 
server interfaces) some MSOs may elect to deploy multiple layers of Policy Servers and to delegate certain policy 
decisions among these servers in order to satisfy requirements associated with scalability and fault-tolerance. 

5.2.2.3.1 Stateful and Stateless Policy Servers 

There are two basic classes of Policy Servers - Stateful and Stateless. A Stateless Policy Server is a slight misnomer 
since it does maintain enough state to map Application Manager requests to the proper CMTS and maintain COPS 
session state, while a pure Stateless Policy Server maintains no state on any of the media sessions. Stateful Policy 
Servers come in several varieties - some participate in admission control and thus monitor the QoS attributes of active 
media sessions, some leave QoS and admission control to the CMTS but monitor time-based or volume-based service 
requests from the Application Manager, and some Policy Servers are somewhere between these extremes. 

The reason there is a variety of Policy Server types is that there is a variety of environments that operators are trying to 
support. For example, some operators may wish to support IPCablecom Multimedia over the same CMTSs that they use 
for IPCablecom telephony, and they may want a single CMS/Policy Server that has a more global view of the network 
resources being used. On the other hand, some operators may wish to run an IPCablecom Multimedia-only 
environment, or they may utilize simpler CMTS-driven mechanisms for partitioning IPCablecom Multimedia and 
telephony resources. These simpler configurations have more modest requirements on the amount of state that a Policy 
Server maintains. 

Policy Server state requirements can also be driven by the level of trust between the Policy Server and Application 
Manager; a Stateful Policy Server can more readily police Application Manager session control behavior than can a 
Stateless Policy Server. So a Stateful Policy Server may be more appropriate for operators supporting third party 
Application Managers. Other operators may rely on economics to enforce their trust relationships with Application 
Managers, or they may control the Application Managers themselves. In such cases a Stateless Policy Server may be 
more appropriate. 

Since it is impossible to categorize all the various components of media session and network QoS state that a Policy 
Server is maintaining, the protocol is designed to be independent of this complexity. A Stateful Policy Server gleans 
IPCablecom Multimedia media session information from the Application Manager requests it proxies; any other 
information it requires is gathered via mechanisms that are outside the scope of the present document. The CMTS and 
the Application Manager make no distinction as to the type of Policy Server to which they are connected, and the 
protocol is designed in such a manner that the type of Policy Server is transparent to the end point. The type of Policy 
Server is only of importance to the operator. 

Since some types of Policy Servers attempt to assist with admission control and may have a larger view of the network 
and its resources, additional state synchronization issues may arise in design in a network which contains more than one 
of these types of Policy Servers. It is the responsibility of the operator to ensure that the efforts of these Policy Servers 
are not undermined by a network that includes other autonomous Policy Servers. 
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5.2.2.3.2 Modification of Requests and Responses by Policy Servers 

Although nominally a part of the Resource Control Domain, the Policy Server can be an intermediary between the 
Service and the Resource Control Domains, in addition to its normal role of implementing cable operator-defined 
authorization and resource management procedures. In either of these capacities it may modify the incoming request 
before forwarding it to the CMTS. 

In acting as an intermediary between the SCD and RCD, the Policy Server may translate fields from formats or scales 
used in the SCD into formats or scales used in the RCD. For example, the Policy Server may modify the "priority" of a 
request coming from an Application Manager (especially important to do for an AM outside of the cable operator 
network) so that this priority field uses a consistent scale throughout the operator's RCD. In its capacity as an 
intermediary, the Policy Server may use bidirectional translation - in other words, it should translate requests from the 
AM to the CMTS and "untranslate" the responses from the CMTS to the AM. This capability can be supported by 
stateful policy servers by remembering the original request, and it can be supported by stateless Policy Servers if the 
translation function is invertible. 

Modification of certain objects, specifically the Classifier and Traffic Profile objects, may cause operational problems 
in the originating AM. As such, these objects shall not be modified by the policy server. Aside from these exceptions, 
all other objects may be policed and modified at the PS's discretion based on provisioned policy rules. 

5.2.2.4 Cable Modem Termination System (CIVITS) 

In describing the role of the CMTS network element, it is important to consider the relation among DOCSIS, 
IPCablecom 1 .x and IPCablecom Multimedia functionality. While each of these suites of specifications addresses a 
specific set of functional requirements, each has also been defined in such a way that corresponding implementations 
may be constructed in a modular manner; either IPCablecom 1 .x or IPCablecom Multimedia Gate Control may be 
layered on top of a DOCSIS 1 . 1 or greater CMTS foundation, with the option of adding additional, complementary 
functionality as business indicates. Further, it should be emphasized that it is a significant asset of the IPCablecom 
architecture that both telephony and Multimedia variants employ considerable architectural similarity, leading to 
potential reuse in the underlying Gate management models. 

The IPCablecom Multimedia CMTS is a generalized version of the IPCablecom 1 .x CMTS that has been defined in 
order to deliver telephony services in IPCablecom 1.x networks. The CMTS is responsible for fulfilling requests for 
QoS that are received from one or more Policy Servers. It performs this function by installing Gates, which are similar 
to the Gates defined in [13]; Gates allow the subscriber's cable modem to request network resources from the CMTS 
through the creation of dynamic DOCSIS flows with guaranteed levels of QoS. The CMTS also sends Event Messages 
detailing actual usage of QoS resources to the Record Keeping Server. 

5.2.2.5 Record Keeping Server (RKS) 

The IPCablecom Multimedia Record Keeping Server fulfils a similar role to the RKS in IPCablecom 1.x [14]. It 
receives Event Messages pertaining to policy decisions from the Policy Server and Event Messages pertaining to QoS 
resource usage from the CMTS. 

In the IPCablecom Multimedia architecture, the Record Keeping Server does not receive messages directly from the 
Application Manager. However, the Application Manager can embed opaque data in messages that it sends to the Policy 
Server, and these data can then be included in Event Messages that are subsequently sent to the RKS. 

5.2.3 IPCablecom Multimedia Interfaces 

IPCablecom Multimedia builds on the IPCablecom 1.x suite of specifications. Where an IPCablecom Multimedia 
interface has a corollary in IPCablecom 1.x, IPCablecom Multimedia uses the same protocol, or an extension of the 
same protocol. 
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Figure 2: IPCablecom Multimedia Architectural Framework 

Table 1 : IPCablecom Multimedia Interfaces 



Interface 


Description 


Notes 


pkt-mm-1 


CMTS - CM 


The Cable Modem (CM) may request QoS from the CMTS via DOCSIS 
DSx signalling. Alternatively, the CMTS may instruct the CM to setup, 
teardown or change a DOCSIS service flow in order to satisfy a QoS 
request, again via DSx signalling. 


pkt-mm-2 


PS - CMTS 


This interface is fundamental to the policy-management framework. It 
controls policy decisions, which may be: (a) pushed by the Policy Server 
(PS) onto the CMTS, or (b) pulled from the PS by the CMTS. 
The interface also allows for proxied QoS requests on behalf of a client. 
In some scenarios, this interface may also be used to inform the PS when 
QoS resources have become inactive. 


pkt-mm-3 


AM -PS 


The Application Manager (AM) may request that the PS install a policy 
decision on the CMTS on behalf of the client. 

This interface may also be used to inform the AM of changes in the status 
of QoS resources. 


pkt-mm-4 


PS - RKS 


The PS sends event messages to the Record Keeping Server (RKS) to 
track policy decisions related to QoS. 


pkt-mm-5 


CMTS - RKS 


The CMTS sends the RKS event messages to track requests for and usage 
of QoS (e.g. service flow additions, changes, deletions, and volume 
metrics). 


pkt-mm-6 


Client - CMTS 


The client may use this interface to directly request and manage QoS 
network resources. If authorized, these resources are provided by the 
CMTS. 


mm-7 


Client - AM 


This interface may be used by the client to interact with the AM and to 
request and manage QoS resources indirectly. This interface is out of 
scope for the present document. 


mm-8 


AM - Peer 


The AM may use this interface to interact with some other entity that is part 
of the application in question. This interface is out of scope for the present 
document. 
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Interface 


Description 


Notes 


mnn-9 


CMTS- 

cable operator- 
Managed IP Network 


This interface on the CMTS may be used in support of end-to-end QoS 
requests beyond the access network. This interface is out of scope for the 
present document. 


mm-IO 


Client - Peer 


The Client may use this interface to interact with some other entity that is 
part of the application in question. This interface is out of scope for the 
present document. 


pkt-mm-11 


AS -AM 


The Application Server uses this interface to send network resource 
requests on behalf of the client to the AM. 

This interface may also be used to notify the AS of changes in the status of 
the network resources. 


mnn-12 


Client - AS 


This interface may be used by the client to interact with the AS and to 
request applications, which indirectly requests network resources. This 
interface is out of scope for the current effort. 



5.2.3.1 



Client and Application Manager Interface (mm-7) 



The interface between the client and the Application Manager is out of scope. Typically, the Application Manager will, 
through some means beyond the scope of the present document, authenticate the client and ensure that the client is 
entitled to the Multimedia service. For example, the client may login to a web page and request service by providing a 
username and password. However it is accomplished, the Application Manager must be able to identify unambiguously 
the cable modem(s) to which service is to be delivered, since this information must be made available to the network 
operator before QoS can be delivered. 



5.2.3.2 



Application Manager and Policy Server Interface (pkt-mm-3) 



This interface corresponds to the IPCablecom 1 .x interface between a Call Agent and a Gate Controller. In IPCablecom 
1.x this is a hidden, non-testable interface, and so there are no pre-existing protocol requirements on this interface. 

IPCablecom Multimedia requires the use of COPS [9] on this interface. In order to simplify the architecture and to 
allow for multiple levels of Policy Server elements between the Application Manager and CMTS, this interface mirrors 
as far as possible the interface between the Policy Server and the CMTS. Although the Application Manager is the one 
requesting resource authorization from the Policy Server, it actually issues this request in a COPS Decision message, 
instead of a COPS Request message. This allows the interface between the Application Manager and the Policy Server 
to appear identical to the interface between the Policy Server and the CMTS. The Application Manager is the PDP 
relative to the Policy Server, and the Policy Server is the PEP relative to the Application Manager. 

When an Application Manager agrees to provide service to a client, it sends a COPS Decision that contains (at least) the 
following information in the form of COPS objects: 

• Identity of the Application Manager making the request 

• Identity of the client(s) to whom service is to be provided 

• RSVP FlowSpec(s) specifying traffic envelope(s) for the session 

In the reply from the Policy Server, the server includes an authorization token, the Gate-ID, which is provided to it by 
the CMTS. 



5.2.3.3 



Policy Server and CMTS Interface (pkt-mm-2) 



This interface is essentially identical to the equivalent interface (between CMTS and Gate Controller) in IPCablecom 
1.x. As in IPCablecom 1.x, COPS is used to transfer policy information between the Policy Server and the CMTS. The 
CMTS acts as a COPS PEP and the Policy Server acts as a COPS PDP. Following the IPCablecom 1.x model, the 
Policy Server initiates communication for a Multimedia session by sending a DQoS Gate-Set message (which is an 
unsolicited COPS DECISION message) to the CMTS. 

This message contains (at least): 

• Application Manager ID 

• Subscriber ID 
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• GateSpec 

• FlowSpec(s) 

• Classifier 

The CMTS responds, as in DQoS, with either Gate-Set- Ack or Gate-Set-Err (both of which are COPS REPORT 

messages). 

If the CMTS responds positively (i.e. with a Gate-Set- Ack), it includes a GatelD. As in IPCablecom 1.x, the GatelD 
acts as an authorization token. Unlike IPCablecom 1.x, the token is not ultimately passed to the client (since Client 
Type 1 endpoints have no knowledge of IPCablecom); instead it is held by the Policy Server (if stateful) and by the 
Application Manager, thus allowing them to issue commands pertaining to this session to the CMTS, either directly in 
the case of the Policy Server, or indirectly via the Policy Server in the case of the Application Manager. 

5.2.3.4 Record Keeping Server and Policy Server Interface (pl^t-mm-4) and 
Record Keeping Server and CMTS Interface (pkt-mm-5) 

The interfaces into the Record Keeping Server from the Policy Server and the CMTS are identical to the equivalent 
interfaces (from CMS and CMTS, respectively) in IPCablecom 1.x (see [14]). These interfaces are used to carry 
IPCablecom Event Messages, which use RADIUS formatting. In IPCablecom Multimedia, Event Messages carry 
detailed information pertaining to the service delivered, including the exact time that service flows are created and 
deleted and (optionally) the amount of traffic that passed over the service flow while it was in existence. 

5.2.3.5 Client and Application Server Interface (mm-1 2) 

The interface between the client and the Application Server is out of scope. Typically, the Application Server will, 
through some means beyond the scope of the present document, authenticate the client and ensure that the client is 
entitled to the Multimedia service. However it is accomplished, the Application Server must be able to identify the 
subscriber to which service is to be delivered, since this information must be made available to the network operator 
before QoS can be delivered. 

5.2.3.6 Application Server and Application Manager Interface (pkt-mm-1 1 ) 

The interface between the Application Server and the Application Manager is defined in [i.2]. IPCablecom Multimedia 
requires the use Web Services on this interface as specified in [i.2]. Application Servers use this interface to send 
network resource requests on behalf of clients to the AM. The interface may also be used by the AM to send 
notifications to the AS of changes in the status of network resources. 

When an Application Server agrees to forward a service request for a client, it sends a Web Service message that 
contains (at least) the following information in the form of message arguments: 

• Subscriber Identifier 

• Service Name 

The interface supports a number of optional arguments that may be used to provide more granularity when requesting 
the service. 

5.2.4 State Information 

In this clause, we provide an overview of state location in an IPCablecom Multimedia system. In addition to 
maintaining detailed state information, devices send information about state transitions to the Record Keeping Server 
for purposes such as billing, fraud detection, session reconstruction, etc. 

5.2.4.1 Application State 

The Application Manager is at all times responsible for maintaining detailed knowledge of the state of the application 
media session. How it does so in detail is beyond the scope of the present document, but it is important to recognize that 
no devices other than the Application Manager are required or expected to maintain any knowledge of the application 

state. 
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The Application Manager may, however, report session state by proxying such information via the PoHcy Server to the 
Record Keeping Server. In addition, some coarse state information (such as the fact that resources have been requested) 
is automatically sent from the Policy Server to the Record Keeping Server. 

5.2.4.2 QoS Resource State 

The CMTS naturally is aware of the detailed state of flows that it manages. The Policy Server (if it is a stateful Policy 
Server) may also maintain a notion of the state of QoS resources on a single CMTS; it may also collate the state 
information over several CMTSs so that it (and only it) knows the QoS state of the entire system. This may be 
important, for example, if an operator has instituted a policy whereby a particular application is not to be permitted to 
consume more than a specified percentage of the total system resources. In a network with only stateless Policy Servers, 
the CMTSs are the only devices to maintain QoS state information. Since stateless Policy Servers do not maintain 
GatelDs, they cannot even interrogate a CMTS to obtain information about a particular Multimedia session. 

Whenever a QoS Resource transitions from one state to another, and whenever a QoS Resource is deleted, a 
corresponding Event Message is sent from the CMTS to the Record Keeping Server. 



Authorization Interface Description 



This clause describes the interface between the Application Manager and the Policy Server, and the interface between 
the PoUcy Server(s) and the CMTS. 

The interface between the Application Manager and the Policy Server is translationally symmetric to the interface 
between the Policy Server and the CMTS. The interfaces are used to pass authorization, reservation and activation 
information to the CMTS, to provide state information from the CMTS to the Policy Server, and from the Policy Server 
to the Application Manager. 

The Application Manager is the PDP for the Service Control Domain. The Policy Server is the PEP with respect to the 
Application Manager and applies Resource Control Domain policies. The Policy Server is a PDP with respect to the 
CMTS, and the CMTS is the PEP with respect to the Policy Server and lies in the actual packet forwarding path. 

This clause describes the use of the COPS protocol to transport IPCablecom QoS messages between the Application 
Manager and Policy Server, and between the Policy Server and CMTS. 

6.1 Gates: The Framework for QoS Control 

An IPCablecom Multimedia Gate is a logical representation of a policy decision that has been installed on the CMTS. A 
Gate is used to control access by a single IP flow to enhanced QoS Services provided by a DOCSIS cable network. 
Gates are unidirectional; a single Gate controls access to a flow in either the upstream or the downstream direction, but 
not both. For a bi-directional IP session, two Gates are required, one for upstream and one for downstream, each 
identified by a unique GatelD. It is important to recognize that this is a fundamental difference from IPCablecom 1.x, in 
which a single GatelD may reference both an upstream and a downstream Gate. 

In IPCablecom Multimedia, each Gate has a separate GatelD. The Gate defines the authorization, reservation and 
committed envelopes to be used by the CMTS to perform authorization, reservation and commit operations. 

Gates can be further qualified as either unicast or multicast. Fundamentally the two Gates are as described above with 
one key differentiator between them - the destination IP address indicated in the classifier object. In a Unicast Gate the 
destination IP address (v4 or v6) contained in the classifier identifies a unicast IP address (or a range of unicast IP 
addresses). A Multicast Gate contains a destination IP address (v4 or v6) in the classifier identifying a multicast IP 
address. See RFC 4291 [i.5] for IPv6 unicast and multicast IP address definitions and RFC 3171 [i.4] for IPv4 multicast 
address assignments. 

Throughout the present document, unless specifically called out as either a Unicast Gate or Multicast Gate, the 
reference to Gate applies to both Gate types. 

In all Scenarios, the CMTS shall perform admission control checks of the envelopes to make sure that the committed 
envelope is less than or equal to the reserved envelope, and the reserved envelope is less than or equal to the authorized 
envelope. (See [1] for specific DOCSIS admission control requirements.) 
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In the "Proxied QoS Policy Push" (Scenario 1) model, the information in a Gate is used by the CMTS to create the 
DOCSIS Service Flow directly, after the CMTS performs the necessary admission control checks of the envelopes. In 
the other two models outlined in [15], "Client requested QoS with Policy Push" (Scenario 2) and "Client requested QoS 
Policy Pull" (Scenario 3), the CMTS uses the Gate information to perform admission control of the client requested 
resources; the CMTS does not initiate creation of the flows. The Application Manager is responsible for issuing Gate 
messages to the Policy Server and the Policy Server is responsible for applying policy rules, and then issuing Gate 
Control messages to the CMTS. 

A Gate consists of the following elements, which are described later in this clause: 

GatelD 

AMID 

SubscriberlD 

GateSpec 

Classifier 

Traffic Profile 

Event Generation Info (optional) 

Time-Based Usage Limit (optional) 

Volume-Based Usage Limit (optional) 

Opaque Data (optional) 

UserlD (optional) 

SharedResourcelD (optional) 

GatelD is the handle for the Gate. The GatelD is assigned by the CMTS and is used by the Application Manager, Policy 
Server, and client to reference the Gate. 

AMID is the handle that identifies the Application Manager and Application Type. 

SubscriberlD uniquely identifies the Client for which the policy is being set. 

GateSpec describes specific authorization parameters defining a Gate (i.e. QoS limits, timers, etc.). 

Classifier describes the IP flow(s) that will be mapped to the DOCSIS Service Flow. 

Traffic Profile describes the QoS attributes of the Service Flow used to support the IP flow. 

Event Generation Information contains information used by the CMTS for the purpose of accounting and usage 
reporting. 

Volume-Based Usage Limit defines a volume cap for traffic traversing the flow associated with the Gate. 

Time-Based Usage Limit describes a time cap limiting the duration of the flow associated with the Gate. 

Opaque Data represents a general-purpose object that remains opaque to the CMTS and PS elements, but which may 
contain data that is significant to the AM. This optional object, if provided by the AM, is retained at the CMTS and 
returned in all associated responses (see clause 6.4.2. 11). 

UserlD identifies the User for which the policy is being set. 

SharedResourcelD indicates the use of a shared underlying resource in fulfilling the request, and uniquely identifies that 
resource. The SharedResourcelD could be used by the Application Manager and Policy Server to aid in understanding 
true resource allocation. A single SharedResourcelD may be associated with multiple gates, allowing an accurate 
summary of resource allocations while preserving the gate's role in identifying a specific policy decision. 

These elements are communicated to the Policy Server and the CMTS via COPS objects and are described in greater 
detail later in this clause. During the installation of the Gate, the information above is communicated to the CMTS. 
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After the installation is complete, a DOCSIS Service Flow can be created. After the creation of the DOCSIS Service 
Flow, the Gate has associated with it an additional element, the DOCSIS Service Flow. 

A Gate transitions through multiple states. In Scenarios 2 and 3, where the client entity is responsible for reserving and 
then activating the DOCSIS Service Flows, a Multimedia Gate behaves in a manner very similar to an IPCablecom 1.x 
DQoS Gate. When the Policy Server installs the Gate onto the CMTS, the Gate is said to be in an "Authorized" state. It 
remains in this state until explicitly deleted by the Policy Server (or, less likely, it is deleted for some reason by the 
CMTS itself) or until a dynamic flow request from the client arrives. 

When the client requests that a dynamic Service Flow be added, it presents the GatelD as an authorization token. The 
CMTS uses the GatelD to perform admission control on the DOCSIS dynamic flow against the authorized envelope 
defined by the Gate. In Scenario 1, the Policy Server instructs the CMTS to transition between the states on behalf of 
the Application Manager, and the CMTS is the entity responsible for initiating and tearing down DOCSIS Service 
Flows. The State Transition clause in the present document describes this behavior. When the CMTS is instructed to 
tear down a DOCSIS Service Flow, its associated Gate remains until explicitly deleted by the PS/AM or until it times 
out and its resources are reclaimed by the CMTS (see clause 6.5.8). In contrast, however, when the PS/AM deletes a 
Gate, the CMTS will delete the associated DOCSIS Service Flow. 



6.1.1 Gate Identification (Gatel D) 



A GatelD is an identifier that is locally allocated by the CMTS where the Gate resides. A GatelD shall be associated 
with only one Gate. Whereas the IPCablecom 1.x DQoS Gate Control model generally assumed a pair of unidirectional 
Gates (one upstream and one downstream) per GatelD in support of a typical two-way voice session, here the 
Gate/GatelD relationship is explicitly one-to-one, so that it is easier to support a wide range of Multimedia services. 

When the Application Manager issues a Gate-Set request, this triggers the Policy Server to issue a Gate-Set message to 
the CMTS. When the CMTS responds with an acknowledgment containing the GatelD, the Policy Server forwards this 
response including the GatelD back to the Application Manager. Note that since there can be a many-to-many 
relationship between a PS and CMTS, the GatelD assigned by one CMTS cannot be guaranteed to be unique across the 
network, so the PSs may use the AMID of the AM along with the SubscriberlD and GatelD in order to uniquely 
identify the Gate. 

An algorithm that may be used to assign values of GatelDs is as follows. Partition the 32-bit word into two parts, an 
index part, and a random part. The index part identifies the Gate by indexing into a small table, while the random part 
provides some level of obscurity to the value. Regardless of the algorithm chosen, the CMTS should attempt to 
minimize the possibility of GatelD ambiguities by ensuring that no GatelD gets reused within three minutes of its prior 
closure or deletion. For the algorithm suggested this could be accomplished by simply incrementing the index part for 
each consecutively assigned GatelD, wrapping around to zero when the maximum integer value of the index part is 
reached. 

6.1 .2 Application Manager Identification (AMID) 

The AMID consists of two fields: the Application Manager Tag and Application Type. Each Application Manager is 
pre-provisioned with an Application Manager Tag that is unique within the universe of a single service provider. The 
Application Manager may also be pre-provisioned with a set of Application Type values that can be used to identify the 
particular application that a gate is associated with. The Application Manager includes the AMID in all messages that it 
issues to the Policy Server. The Policy Server transparently passes this information to the CMTS via Gate Control 
messages. The CMTS shall return the AMID associated with the Gate to the Policy Server. The Policy Server uses this 
information to associate Gate messages with a particular Application Manager and Application Type. 

The Application Manager Tag shall be a globally unique value assigned to the Application Manager by the service 
provider. The Application Manager shall use the assigned Application Manager Tag in all its interactions with Policy 
Servers. Note that since the Application Manager may be operated by a third party, and a single Application Manager 
could interact with multiple service provider operators, a single physical Application Manager may be provisioned with 
multiple Application Manager Tags, and multiple Application Type sets (one for each configured Application Manager 
Tag). 
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6.1 .3 Subscriber Identification (Subscriber! D) 

The SubscriberlD, consisting of the IPv4 or IPv6 address of either the CM or client CPE device (either directly 
connected to the CM or on a routable network behind the CM), identifies the user requesting the service. In complex 
network environments this address may be used to route Gate Control messages between a number of Policy Servers 
and to determine which CMTS is providing service to a particular endpoint. In addition to the IPv4 or IPv6 address, a 
subscriber may also be identified via a FQDN or some opaque data (object defined below) relevant to the service in 
question. 

For a Multicast Gates the CMTS uses the SubscriberlD to decide where the Multicast replication needs to be created. 
The CMTS treats the SubscriberlD as the source IP address of a JoinMulticastSession [1]. If the SubscriberlD is on an 
IP subnet that is not directly connected to the CMTS, the CMTS may reject the Gate as having an invalid SubscriberlD 
see clause 6.4.2.14, IPCablecom Error. 

6.1 .4 Gate Specification (GateSpec) 

The GateSpec describes some high-level attributes of the Gate, and contains information regarding the treatment of 
other objects specified in the Gate message. Information contained in a GateSpec is outlined below: 

• SessionClassID 

• Direction 

• Authorized Timer 

• Reserved Timer 

• Committed Timer 

• Committed Recovery Timer 

• DSCP/TOS Overwrite 

• DSCP/TOS Mask 

SessionClassID provides a way for the Application Manager and the Policy Server to group Gates into different classes 
with different authorization characteristics. For example, one could use the SessionClassID to represent some 
prioritization or preemption scheme that would allow either the Policy Server or the CMTS to preempt a pre-authorized 
Gate in favour of allowing a new Gate with a higher priority to be authorized. 

Direction indicates whether the Gate is for an upstream or downstream flow. Depending on this direction, the CMTS 
shall reserve and activate the DOCSIS flows accordingly. For Multicast Gates the CMTS needs to only support flows or 
gates in the downstream direction. 

Authorized Timer limits the amount of time the authorization must remain valid before it is reserved (see clause 6.2). 

Reserved Timer limits the amount of time the reservation must remain valid before the resources are committed (see 
clause 6.2). 

Committed Timer limits the amount of time a committed service flow may remain idle. 

Committed Recovery Timer limits the amount of time that a committed service flow can remain without a subsequent 
refresh message from the PS/AM once the PS/AM has been notified of inactivity (see clause 6.2). 

DSCP/TOS Overwrite field can be used to overwrite the DSCP/TOS field of packets associated with the DOCSIS 
Service Flow that corresponds to the Gate. This field may be unspecified in which case the DSCP/TOS field in the 
packet is not over-written by the CMTS. This field may be used in both the upstream and downstream directions. The 
CMTS shall support DSCP/TOS overwrite for upstream gates. The CMTS may support DSCP/TOS overwrite for 
downstream gates. If DSCP/TOS is enabled in a downstream gate and the CMTS does not support that function, then 
the field is ignored. 
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6.1.5 Classifier 

A classifier shall be defined for a Gate. Additional classifiers may be included in the original Gate-Set. Classifiers may 
be added or deleted in a subsequent Gate-Set. Compliant implementations shall be able to support a minimum of four 
classifiers when processing a Gate-Set message for Unicast Gates. Compliant implementations shall support a minimum 
of one classifier when processing a Gate-Set message for Multicast Gates. The AM and PS shall not mix unicast and 
multicast destination IP addresses for a single Gate. The classifier identifies the IP flow that will be mapped to the 
DOCSIS service flow associated with the Gate. In Scenario 1, when the CMTS creates the dynamic flow, it shall use the 
Gate classifier as the classifier for the DOCSIS Service Flow according to the rules specified in clauses 9.3.4.1 and 
9.4.3.1. 

There are three types of classifiers defined in the present document; a Classifier, an Extended Classifier, and an IPv6 
classifier, which are described below. For IPv4 traffic, an Application Manager should use the Extended Classifier to 
properly match the traffic it is interested in unless it receives a Gate-Set-Err with either Error-Code 6 (Missing Required 
Object) and Error-Subcode of 6 I 1 (S-Num I S-Type) or Error-Code 7 (Invalid Object) and Error-Subcode of 6 I 2. This 
would occur if the AM is interacting directly with a Policy Server or indirectly with a CMTS that does not support the 
Extended Classifier. In this case, the AM may resend the Gate using the Classifier object instead of the Extended 
Classifier object. The Classifier object is retained for legacy purposes. That being said, the legacy Classifier object will 
be deprecated from the specification in a future release. 

For IPv6 traffic, an Application Manager shall use an IPv6 Classifier. 

For Multicast Gates (where the Destination IP Address in the classifier identifies a specific Multicast IP address) the 
AM encodes the classifier (any of the three classifier types) as follows: 

• The Source IP address and the Mask/Prefix Length combination shall resolve to a specific valid Unicast IP 
address value i.e. not resolve into a range of addresses. If the Source IP address and the Mask/Prefix Length 
combination resolve to the All-Zeros IP Address, it indicates that all Source IP addresses are permitted, 

i.e. Any Source Multicast (ASM). 

• The Destination IP address and the Mask/Prefix Length combination shall resolve to a single specific 
Multicast address. 

• The Source and Destination Port Number fields in the classifier shall be ignored by the CMTS for a Multicast 
Gate. 

The CMTS shall reject a Multicast gate request which does not meet the above stated Multicast gate classifier rules with 
error code 7 (invalid object) and the Error-subcode identifying the invalid classifier object. 

A PS shall support all three types of classifiers specified here. A CMTS shall support both legacy and Extended 
Classifiers. A CMTS that supports DOCSIS 3.0 shall support the IPv6 Classifier. An Application Manager shall use 
only one classifier type per Gate-Set, and shall continue to use that type for all subsequent Gate-Sets for that Gate. 

Throughout the present document, unless stated otherwise, the "classifier" refers generically to either the Classifier 
object. Extended Classifier object, or IPv6 Classifier object, depending on which type was used in the Gate-Set. 

A (legacy) Classifier is an eight-tuple: 

Protocol 

Source IP 

Source Port 

Destination IP 

Destination Port 

Priority 

DSCP/TOS Field 

DSCP/TOS Mask 
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An Extended Classifier is defined by the following tuple: 

Protocol 

IP Source Address 

IP Source Mask 

Source Port Start 

Source Port End 

IP Destination Address 

IP Destination Mask 

Destination Port Start 

Destination Port End 

Priority 

DSCP/TOS Field 

DSCP/TOS Mask 

ClassifierlD 

Activation State 

Action 
An IPv6 Classifier is defined by the following tuple: 

Tc-low 

Tc-high 

Tc-mask 

Flow Label 

Next Header Type 

Source Prefix Length 

Destination Prefix Length 

IPv6 Source Address 

IPv6 Destination Address 

Source Port Start 

Source Port End 

Destination Port Start 

Destination Port End 

ClassifierlD 

Priority 

Activation State 

Action 
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Protocol field, in a legacy Classifier or Extended Classifier, identifies the type of protocol (e.g. IP, ICMP, etc.). The 
Next Header Type field serves a similar function in the IPv6 Classifier. 

Source IP, IP Source Address, or IPv6 Source Address (in the case of Extended Classifier or IPv6 Classifier) is the IP 
address (as seen at the CMTS) of the originator of the IP flow, while Destination IP, IP Destination Address or IPv6 
Destination Address is the termination point for the IP flow. When using an Extended Classifier, a subnet can be used to 
enable classifying multiple IP addresses with a single Extended Classifier object by the use of the IP Source Mask 
and/or IP Destination Mask fields. Similarly, when using the IPv6 Classifier, the Source Prefix Length and Destination 
Prefix Length indicate how many high order bits in the corresponding IPv6 Address to consider in determining a match. 

Source Port and Destination Port specify the UDP or TCP ports for the IP flow. When using an Extended Classifier or 
IPv6 Classifier, the Source Port (Start/End) and Destination Port (Start/End) specify the UDP or TCP port ranges for 
matching the IP flow. 

Priority may be used to distinguish between multiple classifiers that match a particular packet. This is typically set to a 
default value since classifiers are generally intended to be unique. 

When using the legacy Classifier or Extended Classifier, DSCP/TOS field identifies the DSCP/TOS field that must be 
matched for packets to be classified onto the IP flow. To provide for maximum flexibility in defining a network 
management strategy, an accompanying mask is defined which determines which bits in the DSCP/TOS byte are to be 
used as filters in classifying packets. This allows for both DiffServ and TOS strategies (which each define and use 
separate bits within this byte). 

When using IPv6 Classifier the Traffic Class Range and Mask fields, tc-low, tc-high, and tc-mask, allow matching on 
the IPv6 Traffic Class value. An IPv6 packet with IPv6 Traffic Class value "ip-tc" matches this parameter if 
tc-low < (ip-tc AND tc-mask) < tc-high. If the tc-mask field is set to 0, then comparison of the IPv6 packet Traffic Class 
byte for this entry is irrelevant. 

NOTE: The value Ox3F for tc-mask will exclude the Explicit Congestion Notification [i.3] bits from the 
comparison, and hence will result in classification based on DSCP [7]. 

The Flow Label field matches the Flow Label used in the IPv6 header. The 20 least significant bits represent the 20-bit 
IPv6 Flow Label while the 12 most significant bits are ignored. If this parameter is set to 0, then comparison of IPv6 
flow label for this entry is irrelevant. 

A classifier may have wild-carded fields (indicated by zeroed fields, unless otherwise specified), but care must be taken 
so that multiple IP flows do not unintentionally match the same classifier, which can lead to unexpected results. 

Fields unique to the Extended Classifier and IPv6 Classifier: 

• The ClassifierlD field is used as an identifier for the classifier. It can be used to reference an existing classifier 
when making changes to that classifier. 

• The Activation State field is used to instruct the CMTS to either activate or inactivate the classifier. 

• The Action field is used to add, replace, or delete the classifier. 

6.1.6 Traffic Profile 

There are four basic ways to express the Traffic Profile for a Gate: 

1) FlowSpec 

2) DOCSIS Service Class Name, or 

3) DOCSIS -Specific Parameterization 

4) Upstream Drop 

The Policy Server or Application Manager shall define the Traffic Profile for a Gate using one of the following: (1) the 
FlowSpec, (2) DOCSIS Service Class Names, (3) DOCSIS -Specific Parameters, or (4) Upstream Drop. All envelopes 
used in a Traffic Profile shall be the same type, i.e. either FlowSpec, DOCSIS Service Class Names, DOCSIS-Specific 
Parameters or Upstream Drop. 
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There shall be at least one set of Traffic Profile parameters specified when the Gate is first being installed. The Policy 
Server and Application Manager may specify a second set to represent the reserved envelope, and a third set to 
represent the committed envelope. If the CMTS is told to immediately create a dynamic flow upon receipt of a Gate-Set 
message (via the presence of the reserved or committed envelopes), the CMTS shall use the reserved and committed 
envelope Traffic Profile parameters to perform the DOCSIS messaging to create the flow, in the direction specified by 
the Direction field in the GateSpec (provided the request is authorized and sufficient resources exist to satisfy the 
request). When told to transition into the Committed state, the CMTS shall use the Traffic Profile to activate the 
DOCSIS Service Flow. As an optimization, the Policy Server may tell the CMTS to perform all three actions (authorize, 
reserve and commit) on behalf of the Application Manager via a single Gate Control message. Alternatively, the PS/AM 
may issue separate Gate-Set messages to tell the CMTS to authorize and reserve and then to commit via a subsequent 
Gate-Set message. 

6.1.6.1 FlowSpec 

The FlowSpec object contains RSVP FlowSpecs that are used to describe the Traffic Profile of the IP flow. The 
FlowSpec object can contain multiple RSVP FlowSpecs: 

• FlowSpec that defines the authorization resource envelope against which future reservations can be made. 

• FlowSpec that defines the reserved envelope against which future commit requests can be made. 

• FlowSpec that defines the resources to be committed. 

RSVP FlowSpecs support two types of services: controlled load [5] and guaranteed [6]. The main difference between 
the two types of services is discussed in clause 8. The two types of services are distinguished based on the FlowSpec 
Service number, which is specified in the RSVP FlowSpec. Service number 5 is for controlled load, and Service number 
2 is for guaranteed. A controlled load service shall contain only the TSpec token bucket parameters, and not the RSpec. 
A guaranteed service shall contain both the TSpec and the RSpec. 

Please refer to clause 8 for information on how to explicitly map RSVP parameters into DOCSIS parameters. When 
deriving the DOCSIS parameters using the RSVP FlowSpec parameters, there are some DOCSIS parameters that are 
highly approximated. If the approximations do not give the Policy Server or Application Manager the control it desires, 
the PS/AM may use the other methods of defining the Traffic Profile, which includes the ability to define some 
DOCSIS -specific parameters. These parameters allow the Policy Server or Application Manager to fine-tune the 
standard mapping of FlowSpecs to DOCSIS parameters. 

6.1 .6.2 DOCSIS Service Class Name 

The DOCSIS Service Class Name indicates the DOCSIS Service Class to be used to describe the QoS attributes. A 
CMTS shall support DOCSIS Service Class Names. 

DOCSIS Service Class Name enables one to use pre-provisioned DOCSIS QoS parameters on the CMTS. On the 
CMTS, one can configure DOCSIS Named Service Classes with different DOCSIS QoS profiles, then reference the 
DOCSIS Service Class Name in the Gate to indirectly associate a QoS profile with a particular Gate. When using the 
DOCSIS Service Class Name traffic profile, values in the GateSpec, with the exception of the direction flag, shall 
overwrite the equivalent defined parameter value in the Service Class Name. For example, if T3 is 30 seconds in the 
GateSpec and the Service Class Name defined the Timeout for Active QoS Parameters to 20, the value in the GateSpec, 
i.e. 30, will be used. This currently applies to the GateSpec DSCP/TOS Overwrite, DSCP/TOS Mask, T2 and T3H-T4, 
which map to the DOCSIS tos-or-mask, tos-and-mask. Timeout for Admitted QoS Parameters and Timeout for Active 
QoS Parameters respectively. If the CMTS receives a GateSpec with a direction flag that does not match the direction 
associated with the Service Class Name specified in the Gate-Set, the CMTS shall send a Gate-Sate-Err with error 
code 11 (Undefined Service Class Name). 

For more information on DOCSIS Service Classes please refer to clause 7.5.3 of the DOCSIS specification [1]. 

6.1 .6.3 DOCSIS Specific Parameterization 

The third way of defining the Traffic Profile consists of using DOCSIS-specific Traffic Profile; this allows the 
Application Manager to explicitly specify the DOCSIS parameters of the DOCSIS flow. If the Application Manager 
wishes to use this third way of defining a Traffic Profile, it shall include an object containing the DOCSIS Specific 
Parameters. 
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All DOCSIS Service Flow Scheduling types are supported via several different Traffic Profile S-Types. Each S-Type 
has a different encoding of the DOCSIS -specific parameters relevant to that Service Flow Scheduling type. For further 
details regarding DOCSIS-specific parameterization refer to clause 6.4.2.7. 

6.1.6.4 Upstream Drop 

An Upstream Drop Traffic Profile represents a null service flow for upstream traffic filtering at the CM. DOCSIS 3.0 
refers to a null service flow at the CM as an Upstream Drop Classifier (UDC). An AM can push an Upstream Drop 
Traffic Profile to the CMTS, via the PS, which pushes the UDC to the CM. When a CM installs a UDC all data packets 
meeting the criteria of the classifier are dropped at the CM. 

6.1 .7 Event Generation Info 

This object contains information relevant to the CMTS in support of accounting and billing functions. Attributes 
include: 

• Primary Address: Port of the Primary Record Keeping Server to which the CMTS shall send event records. 

• Secondary Address: Port of the Secondary Record Keeping Server, the CMTS shall use as specified in [14] if 
the primary is unavailable. 

• BillingCorrelationlD, which the CMTS shall pass to the Record Keeping Server with each event record. 

Omission of the Event Generation Info object indicates that the CMTS shall not generate Event Messages for a specific 
Gate. 

There are two versions of the Event Generation Info object: an IPv4 Event Generation Info object and an IPv6 Event 
Generation Info object to accommodate IPv4 and IPv6 Address values respectively. 

6.1 .8 Time-Based Usage Limit 

This object specifies amount of time a Gate can remain committed before meeting the time limit threshold for this Gate. 
The CMTS is not responsible for enforcing time limits, but shall store this object and return it upon request. 

6.1.9 Volume-Based Usage Limit 

The Application Manager uses the Volume-Based Usage Limit to signal the CMTS to generate a Gate Control message 
when the specified amount of data has traversed the Gate. The CMTS is not responsible for enforcing volume limits, but 
shall signal to the PS/AM when a volume limit is reached. 

6.1.10 Opaque Data 

Opaque Data consists of general information that a Policy Server or Application Manager can store on a CMTS. This 
data remains opaque to the CMTS, but contains information useful for the PS or AM. If provided by the PS/AM, the 
CMTS will return this object in all responses (see clause 6.4.2.1 1). 

6.1.11 Gate Time Info 

Gate Time Info contains a timestamp representing the time the Gate was committed. This may be queried and used by a 
Policy Server or Application Manager to enforce time-based network policy. 



6.1.12 Gate Usage Info 



Gate Usage Info consists of an octet counter indicating the number of bytes of data transmitted over this Gate (see 
clause 6.4.2.13). Analogous to the Gate Time Info object, this information may be used by a Policy Server or 
Application Manager to enforce volume-based network policy. 
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6.1 .13 User Identification (UserlD) 



The UserlD is a UTF-8 string value that identifies the user requesting the service. As defined earlier the SubscriberlD 
defines the actual device requesting the service, but there may be multiple users that share that device. The UserlD field 
allows the elements that manage the QoS to associate a request with a specific user. 

6.1.14 SInared Resource Identification (SharedResourcelD) 

The SharedResourcelD is only applicable to Multicast Gates and is locally generated by the CMTS. When a Multicast 
Gate request is successfiilly processed by the CMTS, the CMTS shall return a SharedResourcelD in the Gate-Set- Ack 
to the Policy Server. 

The CMTS shall not include a SharedResourcelD in Gate-Set- Ack messages in response to a Unicast Gate request. 

The presence of the SharedResourcelD indicates to the PS and AM that resources used in fulfilling the Multicast Gate 
request are either already shared with a previous Multicast Gate request, or may be shared by future Multicast Gate 
requests. The SharedResourcelD essentially identifies the Multicast Group Service Flow on the DOCSIS network. 

The method of allocation of SharedResourcelDs is an implementation option of the CMTS. However, the CMTS shall 
ensure the uniqueness of all current SharedResourcelD values within the scope of the CMTS. The CMTS should 
attempt to minimize the possibility of SharedResourcelD ambiguities by ensuring that no SharedResourcelD is reused 
for a different underlying resource within a reasonable duration after the prior closure or deletion of the last gate 
associated with the SharedResourcelD in question. 

While each PS may communicate with many CMTSs, a SharedResourcelD assigned by one CMTS cannot be 
guaranteed to be unique across the network. The PS may use additional information, such as the associated CMTS 
identity, in order to uniquely identify the shared resource. 

NOTE: The SharedResourcelD does not replace the GatelD, but instead supplements it by providing information 
about the underlying resource being utilized for a Multicast Gate. The GatelD remains the primary and 
unique identifier of the Gate. 

6.2 Gate Transitions 

As briefly outlined earlier, a Gate may reside in the following logical states: 

• Authorized - a Policy Server has authorized the flow with resource limits defined 

• Reserved - resources have been reserved for the flow 

• Committed - resources are active and are being used 

• Committed-Recovery - inactivity has been detected on the flow; resource recovery pending 

For the state machine depicted in figure 3, the CMTS shall complete the triggering event with a successful outcome 
before it transitions a gate from one state to another. For Gate Control events, the CMTS shall not change state until the 
request has been fully processed (including any resulting flow transitions) and the CMTS has determined that a success 
acknowledgement is to be transmitted. 
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Figure 3: Gate State Transitions 

The CMTS shall support Gate states and transitions as shown in figure 3 and described in this clause. The CMTS shall 
also implement transitions for protocol error processing. 

In this clause we describe the state transitions of the Gate in the CMTS that result from external events (Gate Control 
messages from the Policy Server), as well as transitions that result from internal events (e.g. timer expiration). Note that 
the Policy Server is not the source of the external events; instead the Policy Server is merely acting as a proxy for the 
Application Manager, which is the trigger for the events. 

6.2.1 Authorized 

A Gate is created in the CMTS by a Gate-Set command from the Policy Server. The CMTS allocates a unique identifier 
called a GatelD. The Gate is now said to be in the Authorized state and the CMTS shall start Timer Tl. Timer Tl limits 
the amount of time the authorization remains valid. 



£75/ 



36 ETSI TS 1 02 879 V1 .1 .1 (201 0-06) 

A Gate in the Authorized state shall be deleted upon receipt of a Gate-Delete message. When this happens, the CMTS 
shall respond with a Gate-Delete-Ack message and shall stop Timer Tl. 

The CMTS is required to support the following state transitions while a Gate is in the Authorized state: 

Authorized State Transitions: 

• Authorized Loopback to Authorized: Modify Authorized Envelope 

• Authorized to Reserved (defines Reserved Envelope < Authorized Envelope) 

• Authorized to End (deletes Authorized Envelope) 

The CMTS shall not support any other state transitions for a Gate in the Authorized state, but a number of separate 
stimuli may result in the transitions described. 

When the Gate is installed, it is said to be in an Authorized State. While in the Authorized state, the Policy Server may 
modify any of the parameters associated with a Gate (e.g. Traffic Profile, Classifier, etc.). If in a Authorized state a 
Gate-Set message is received that does not transition the Gate to the Reserved or Committed states, then the CMTS 
shall restart timer Tl. 

While in the Authorized state, the CMTS shall transition the Gate into the Reserved state upon successful request of the 
Policy Server. The CMTS shall transition the Gate into the End state upon receipt of a Gate-Delete from the Policy 
Server or upon Tl timer expiration. 

6.2.2 Reserved 

A Gate in the Authorized state is expecting the client to attempt to reserve resources. In Scenario 1, the Policy Server 
reserves the resources on the client's behalf. To reserve resources, the Policy Server shall issue a subsequent Gate-Set 
message with a Traffic Profile that includes the Reserved Envelope. On receipt of this reserve request, the CMTS shall 
verify the request is within the authorization limits established for the Gate and perform admission control procedures. 

If the Reserve request does not arrive before Timer Tl expires, the CMTS shall delete the Gate, and notify the Policy 
Server of the state change. If admission control succeeds and only resource reservation was requested, the CMTS shall 
put the Gate in the Reserved state. Simultaneously, the CMTS shall also stop timer Tl and start timer T2 (Reserved 
Timer). If admission control procedures are not successful, the CMTS shall maintain the Gate in the Authorized state 
and provide a Gate-Set-Err response to the PS. 

The CMTS is required to support the following state transitions while a Gate is in the Reserved state: 

Reserved State Transitions: 

Reserved Loopback to Reserved: Modify Authorized Envelope (> Reserved Envelope) 

Reserved Loopback to Reserved: Modify Reserved Envelope (< Authorized Envelope) 

Reserved to Authorized (deletes Reserved Envelope and replaces Authorized Envelope) 

Reserved to Committed (defines Committed Envelope < Reserved Envelope) 

Reserved to End (deletes Reserved and Authorized Envelopes) 

The CMTS shall not support any other state transitions for a Gate in the Reserved state, but a number of separate stimuU 
may result in the transitions described. 

From the Authorized state, the CMTS shall transition the Gate into the Reserved state, if requested by the Policy Server 
as long as the Reserved envelope is less than or equal to the Authorized envelope, the request passes admission control, 
and the flow is successfully reserved. Once in the Reserved state, the Gate's Authorized envelope may be modified via a 
Gate-Set message. The Gate's Reserved envelope can also be modified in the Reserved State (see clause 6.5.6). If in a 
Reserved state a Gate-Set message is received that does not transition the Gate to the Authorized or Committed states, 
then the CMTS shall restart timer T2. 

If the Commit request does not arrive before timer T2 expires, the CMTS shall delete the Gate, and notify the Policy 
Server of the state change. 
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The Reserved envelope shall always be less than or equal to the Authorized envelope. In the Reserved state, for a 
CMTS to transition a Gate to the Committed state, the Committed Envelope shall be less than or equal to the Reserved 
Envelope (see clause 6.5.3). 

While in the reserved state, the Policy Server may modify the Authorized envelope by specifying a new Traffic Profile 
in a Gate-Set message. The new Traffic Profile will define a modified Authorized envelope, and the same Reserved 
Envelope that was used previously to transition the Gate into the Reserved state. However, all requests to modify 
Authorized, Reserved, or Committed envelopes shall conform to the general rule: 

Authorized Envelope > Reserved Envelope > Committed Envelope 

The Policy Server may delete a Gate in the Reserved state by issuing a Gate-Delete message. 

6.2.3 Committed 

In the Reserved state the Gate is expecting the client to commit resources, and thereby activate them. In Scenario 1, the 
Policy Server commits the resources on the client's behalf. To commit resources, the Policy Server shall issue a Gate- 
Set command with a Traffic Profile that includes the Committed Envelope. The CMTS shall authorize the requested 
Committed envelope against the Reserved envelope, assuming the Reserved and Authorized envelopes remain 
unchanged. If the authorization succeeds, the CMTS shall start timer T3, and either stop timer T2 if the Reserved 
envelope equals the Committed envelope or restart timer T2 if the Reserved Envelope is greater than the Committed 
envelope. If the authorization fails, the CMTS shall leave the state of T2 timer unmodified. 

Note that once the DOCSIS Service Flow has been activated, the CMTS shall refresh timer T3 when data is transferred 
over the flow. If there is no activity on the flow for time equal to T3, the CMTS shall notify the Policy Server of the 
state change. Likewise, the Policy Server shall notify the Application Manager of the state change. 

In the Committed state, the Application Manager may delete the Gate by issuing a Gate-Delete message to the Policy 
Server, which in turn shall relay the message onto the CMTS. If the Policy Server issues a Gate-Delete message to the 
CMTS, the CMTS shall delete the Gate and the corresponding Service Flow, and stop timers T2 and T3 if they are 
running. 

The CMTS is required to support the following state transitions while a Gate is in the Committed state: 

Committed State Transitions: 

Committed Loopback to Committed: Modify Authorized Envelope (> Reserved Envelope) 

Committed Loopback to Committed: Modify Reserved Envelop (> Committed Envelope and < Authorized 
Envelope) 

Committed Loopback to Committed: Modify Committed Envelop (< Reserved Envelope) 

Committed to Reserved (deletes Committed Envelope) 

Committed to Committed-Recovery: (initiate resource recovery process) 

Committed to End (deletes Committed, Reserved and Authorized Envelopes) 

The CMTS shall not support any other state transitions for a Gate in the Committed state, but a number of separate 
stimuli may result in the transitions described. 

While in the Reserved State, the CMTS shall transition a Gate to the Committed state, if requested by the Policy Server 
as long as the Committed Envelope is less than or equal to the Reserved Envelope (see clause 6.5.3). While in the 
Committed state, the Policy Server may modify the Authorized Envelope of the Gate via a Gate-Set message, as long as 
the Authorized Envelope is greater than or equal to the Reserved Envelope. In this state, the Policy Server may also 
modify the Reserved envelope, as long as the reserved envelope is greater than or equal to the Committed Envelope. In 
this state, the Policy Server may even modify the Committed envelope, as long as the new envelope is less than or equal 
to the Reserved Envelope. If a request is received to de-commit all resources (but keep them reserved) while the Gate is 
in the Committed state, the CMTS shall stop timer T3, (re-)start timer T2, and transition back to the Reserved state. In 
Scenario 1, the Policy Server may request this action by issuing a Gate-Set message with the a Traffic Profile that 
includes the Authorized and Reserved Envelopes, but does not include a Committed Envelope. 
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While in the Committed state, the CMTS shall transition a Gate to the End state upon receiving a Gate-Delete message 
from the Policy Server. While in the Committed state, the Policy Server may modify the Authorized or Reserved 
envelope by simply specifying the new Traffic Profile; the new Traffic Profile shall contain modified Authorized or 
Reserved envelopes, and the same Committed Envelope that was used previously to transition the Gate into the 
Committed state. 

When (re-)entering the Committed state due to the receipt of a Gate-Set message, the CMTS shall (re-)start timer T2 if 
the Reserved Envelope is greater than the Committed Envelope, or shall stop timer T2 if it was previously running and 
the Reserved Envelope is now equal to the Committed Envelope. 

While in the Committed state: 1) If the timer T2 expires the Gate shall remain in the Committed state, the T3 timer shall 
be reset, and the CMTS shall send a Gate-Report-State with Reason code 9 (Gate state unchanged, but T2 timer 
expiration caused reservation reduction) to the Policy Server indicating the reduction in reserved resources. 2) If a 
Gate-Set transitions the Gate back to the Reserved state the timer T2 shall be started if it was not running and restarted 
if had previously been running, and 3) If a transition to the End state occurs both the timer T2 and T3 shall be stopped if 
they are running. 

As an optimization, for Scenario 1, the Policy Server may Authorize, Reserve, and Commit at the same time by issuing 
a Gate-Set message with the Traffic Profile that includes all three envelopes set such that the CMTS is told to execute 
all three actions sequentially without any further interaction from the Policy Server - that is, they must all succeed (if so, 
the CMTS shall indicate this by a Gate-Set- Ack) or fail (if so, the CMTS shall indicate this by a Gate-Set-Err). 

From the Committed state, the Gate transition to the Committed-Recovery state due to the expiration of the T3 timer. If 
the CMTS detects that there has been no activity on the associated flow for a duration of T3, the CMTS shall start the 
T4 timer, generate a Gate-Report-State message to the Policy Server indicating that the flow has been inactive for time 
duration defined by T3 and transition to the Committed-Recovery state, while leaving the associated flow in the 
activated state. The Policy Server shall relay the Gate-Report-State message to the Application Manager. The 
Application Manager shall either refresh the policy by issuing a Gate-Set message, or remove the Gate by issuing a 
Gate-Delete message. 

Certain applications may not wish to be notified when activity on the flow ceases. In this case, the Application Manager 
may set the T3 timer (which corresponds to the DOCSIS Active Timer) to 0. As specified in [1] a value of for the 
DOCSIS Active Timer indicates that activity detection on the CMTS is turned off for that flow. Thus, the Gate will 
remain in the Committed state forever until either a Gate-Delete is received or the CM goes offline. 



6.2.4 Committed-Recovery 



In the Committed state the flow associated with the Gate is active. If the CMTS detects that the flow is unused for a 
time in excess of the T3 timer, the CMTS notifies the PS (who notifies the AM) that the service-flow associated with 
the gate has been unused, starts the T4 timer and transitions the Gate to the Committed-Recovery state. 

NOTE: If the T2 timer is running it will continue running. It shall not be reset. 

The AM must decide to either refresh the policy by issuing a Gate-Set message to the PS or delete the Gate by issuing a 
Gate-Delete message to the PS. The Policy Server shall forward the Gate-Set message or Gate-Delete message to the 
CMTS. 

If, while in the Committed-Recovery state, the CMTS receives a Gate-Set message for the Gate before the timer T4 
expires, then the CMTS shall stop the T4 timer, restart the T3 timer, transition the Gate back to the Committed state and 
(re-)start the T2 timer if the Reserved Envelope is greater than the Committed Envelope or stop the T2 timer if it is 
running and the new Reserved Envelope is equal to the Committed Envelope. If the authorization fails, the CMTS shall 
leave the state of the T4 and T2 timers unmodified. 

If, while in the Committed-Recovery state, the CMTS receives a Gate-Delete message before the timer T4 expires, then 
the CMTS shall stop the T4 Timer, delete the Gate and the corresponding service flow, and stop the T2 timer if it is 
running. 

If the timer T4 expires while in the Committed-Recovery state, then the CMTS shall send a Gate-Report-State message 
to the PS, stop the T2 timer if it is running, tear down the service flow associated with the Gate, and then delete the 
Gate. Likewise, the Policy Server shall notify the Application Manager of the state change. 

If the timer T2 expires while in the Committed-Recovery state, then the Gate shall remain in the Committed-Recovery 
state and the CMTS shall send a Gate-Report-State with Reason code 9 (Gate state unchanged, but T2 timer expiration 
caused reservation reduction) to the Policy Server indicating the reduction in reserved resources. 
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The CMTS is required to support the following state transitions while a Gate is in the Committed-Recovery state: 
Committed -Recovery State Transitions: 

• Committed-Recovery to Committed: (policy has been refreshed) 

• Committed-Recovery to End (deletes Committed, Reserved and Authorized Envelopes) 

• Committed-Recovery to Committed-Recovery (Timer T2 Expiry; send Gate-Report-State) 

The CMTS shall not support any other state transitions for a Gate in the Committed-Recovery state, but a number of 
separate stimuli may result in the transitions described. 

There may be applications that do not wish to keep a Gate once inactivity has been detected. In this instance, the AM 
may set the T4 timer to zero. When T4 is set to zero, the Committed-Recovery state is bypassed. In this case, when the 
T3 timer expires the CMTS shall send a Gate-Report-State message to the PS (with reason code = 5), stop the T2 timer 
if it is running, tear down the service flow associated with the Gate, and then delete the Gate. Likewise, the Policy 
Server shall notify the Application Manager of the state change. 



6.3 



COPS Profile for IPCablecom Multimedia 



As defined earlier, admission control involves the process of managing QoS resource requests based on administrative 
policies and available resources. High-level operational modules associated with this process are depicted in [15]. 
Under this model administrative policies are stored in a policy database and controlled by the Policy Server. 
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Figure 4: QoS Admission Control Layout 
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Admission control decisions made by the Policy Server shall be communicated to the CMTS or Application Manager 
using COPS. The CMTS may make QoS Admission Control requests to the COPS Server based on network events 
triggered by either the QoS signalling protocol, or via data flow detection mechanisms. The network event can also be 
in need of QoS bandwidth management, e.g. a new QoS capable interface becomes operational. 

QoS policy decisions made by the Policy Server may be pushed to the CMTS based on a request from the Application 
Manager. The CMTS may access that decision information to make policy enforcement decisions on incoming session 
requests received at the CMTS. The CMTS shall not support CM-initiated DSx messages in IPCablecom Multimedia. 
The CMTS shall treat a CM-initiated DSx message as a request with an invalid GatelD. 

A COPS client/server configuration supporting QoS Admission Control is specified in the lETF's COPS protocol [9]. 
This protocol includes the following operations: 

• Client-Open (OPN)/Client- Accept (CAT)/Client-Close (CC). The COPS client (PEP) sends an OPN message 
to initiate a connection with the COPS server (PDP), and the server responds with a CAT message to accept 
the connection. The server or client sends a CC message to terminate the connection. 

• Request (REQ). The client sends a REQ message to the server to request admission control decision 
information or device configuration information. The REQ message may contain client-specific information 
that the server uses, together with data in the session admission policy database, to make policy-based 
decisions. 

• Decision (DEC). The server responds to REQs by sending a DEC back to the client that initiated the original 
request. DEC messages may be sent immediately in response to a REQ (i.e. a solicited DEC) or at any time 
after to change or update a previous decision (i.e. an unsolicited DEC). 

• Report-State (RPT). The client sends a RPT message to the server indicating changes to the request state in the 
client. The client sends this to inform the server of the actual resource reserved after the server has granted 
admission. The client can also use Report-State to periodically inform the server the current state of the client. 

• Delete-Request-State (DRQ). The client sends a DEL message to the server to request state cleanup. This may 
be the result of QoS resource release by the client. 

• Keep- Alive (KA). Sent by both the client and server for communication failure detection. 
Within the IPCablecom Multimedia architecture, the PDP-PEP relations are as follows: 

• The Application Manager is a COPS Policy Decision Point (PDP) relative to the Policy Server. 

• The Policy Server is a PEP relative to the Application Manager. 

• The Policy Server is a PDP relative to the CMTS. 

• The CMTS is a PEP relative to the Policy Server. 

Although the content of COPS messages required for IPCablecom Multimedia are consistent with the COPS protocol, 
there is a slight difference in the way the COPS session starts, and a relaxation of response ordering requirements. 
RFC 2748 [9] states: 

"The COPS protocol uses a single persistent TCP connection between the PEP and a remote PDP. One PDP 
implementation per server shall listen on a well-known TCP port number (COPS=3288 [lANA]). The PEP is 
responsible for initiating the TCP connection to a PDP". 

The last line of the statement says that the PEP is responsible for initiating the TCP connection. In contrast, in the 
IPCablecom model, the CMTS (PEP) is the one that listens on the assigned port 3918, and it is the Policy Server that 
shall initiate the TCP connection to the CMTS. This is the opposite of the model described in the RFC. However, once 
the TCP connection is in place, the CMTS behaves in a manner consistent with the client, or PEP, in the COPS 
protocol. Similarly, the Policy Server (PEP) listens on the assigned port 3918 and it is the Application Manager that 
shall initiate the TCP connection to the Policy Server. 

Note that IPCablecom Multimedia and IPCablecom 1 .x DQoS listen on different ports so that the CMTS may initiate 
the COPS session with the proper Client-Type. 
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RFC 2748 [9] also states: 



"RPT messages solicited by decisions for a given Client Handle shall set the Solicited Message flag and shall 
be sent in the same order as their corresponding Decision messages were received". 

The COPS protocol uses the order of RPT and Decision messages to match requests to responses. In contrast, 
IPCablecom Multimedia implementations shall use the TransactionID object to match responses with requests and 
should send RPT messages as soon as they are ready. 

The details of the COPS protocol are provided in [9]. This IETF RFC provides a description of the base COPS protocol, 
independent of Client-Type. The IPCablecom architecture is also aligned with the RFC 3084 [12] document. COPS-PR 

states: 

"In COPS-PR, policy requests describe the PEP and its configurable parameters (rather than an operational 
event). If a change occurs in these basic parameters, an updated request is sent. Hence, requests are issued 
quite infrequently. Decisions are not necessarily mapped directly to requests, and are issued mostly when the 
PDP responds to external events or PDP events (policy updates)". 

When this concept is mapped to the IPCablecom Multimedia architecture, the PEP issues a Request to the PDP, 
specifying a Client-Handle. This Client-Handle is then used in all future Decision messages from the PDP to the PEP. 
These Decision messages carry the Gate Control messages (i.e. Gate-Set, Gate-Info and Gate-Delete) defined for the 
DQoS and Multimedia Client-Types. The Client-Handle is used to uniquely identify the PDP-PEP association. 

In the IPCablecom Multimedia architecture, there can be multiple Application Managers interacting with one or more 
Policy Servers. There is a single instance of a IPCablecom Multimedia COPS session per TCP connection; where a 
IPCablecom Multimedia COPS session refers to the Gate messages between the PDP and PEP associated with a single 
Client-Handle. This means there is one COPS-TCP connection between an Application Manager and a Policy Server. 
Similarly, there can be one or more Policy Servers talking to one or more CMTSs. When connected to multiple PDPs, 
the PEP shall ensure that the Client-Handle used is unique per association. 

6.4 Gate Control Protocol Message Formats 

Protocol messages for Gate Control shall be transported within the COPS protocol messages. The PDP and PEP shall 
establish and use a TCP connection for communication, and utilize the mechanisms specified in [16] to secure the 
communication path. 



6.4.1 COPS Common Message Format 



Each COPS message consists of the COPS header followed by a number of typed objects. The Application Manager, 
Policy Server and CMTS shall use the COPS Common Message format as defined below as the message format for all 
message exchanges. In the object specifications that follow, each row represents a 4-byte word as all objects align on 
4-byte word boundaries. 






1 


2 |3 


Version Flags 


Op-Code 


Client-Type 


Message Length 



Version is a 4-bit field giving the current COPS version number. This field shall be set to 1 . 

Flag is a 4-bit field. The least significant bit is the solicited message flag. When a COPS message is sent in response to 
another message (e.g. a solicited decision sent in response to a request) this flag shall be set to 1. In other cases (e.g. an 
unsolicited decision) the flag shall not be set (value = 0). In keeping with the DQoS model, the first Decision message 
sent in response to a Request message is a solicited response and its solicited message flag shall be set. All other 
Decision messages are unsolicited and the solicited message flag shall be cleared. All other flags shall be set to zero. 

Op-code is a 1-byte unsigned integer field that gives the COPS operation to be performed. COPS operations used in this 
IPCablecom specification are: 

1 = Request (REQ) 

2 = Decision(DEC) 
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3 = Report-State (RPT) 

4 = Delete Request State (DRQ) 

6 = Client-Open (OPN) 

7 = Client-Accept (CAT) 

8 = Client-Close (CC) 

9 = Keep-Alive (KA) 

Client-Type is a 2-byte unsigned integer identifier. For IPCablecom Multimedia use, the Client-Type shall be set to 
IPCablecom Multimedia client (OxSOOA). For Keep- Alive messages (Op-code = 9) the Client-Type shall be set to zero, 
as the KA is used for connection verification rather than per-client session verification. 

Message Length is a 4-byte unsigned integer value giving the size of the overall message in octets. Messages shall be 
aligned on 4-byte boundaries, so the length shall be a multiple of four. 

Following the COPS common header are one or more objects. All the objects shall conform to the same object format 
where each object consists of one or more 4-byte words with a four-octet header, using the following format. 



|1 


2 


3 


Length 


C-Num 


C-Type 


Object Contents 



Length is a 2-byte unsigned integer value that shall give the number of bytes (including the header) that compose the 
object. If the original length in octets is not a multiple of four, padding shall be added to the end of the object so that it 
is aligned to the next 4-byte boundary. 

C-Num identifies the class of information contained in the object, and the C-Type identifies the subtype or version of 
the information contained in the object. Standard COPS objects (as defined in [9]) used in the present document, and 
their C-Num values, are: 

1 = Handle 

2 = Context 
6 = Decision 

8 = Error 

9 = Client Specific Info 

10 = Keep- Alive-Timer 

1 1 = PEP Identification 

12 = Report Type 

Each of these objects shall conform to the format and rules relating to the individual object as defined in [9]. 

6.4.2 Additional COPS Objects for Gate Control 

As with the COPS-PR and COPS-RSVP profiles, the IPCablecom Client-Type defines a number of additional object 
formats. These objects shall be placed inside a Decision object, C-Num = 6, C-Type = 4 (Client Specific Decision Data) 
when carried from PDP to PEP in a Decision message. They shall also be placed in a ClientSI object, C-Num = 9, 
C-Type = 1 (Signaled ClientSI) when carried from the PEP to the PDP in a Report State message or Client-Open 

message. 

These objects are encoded similarly to the client-specific objects for COPS-PR and as in COPS-PR these objects are 
numbered using a client-specific number space, which is independent of the top-level COPS object number space. For 
this reason, the object numbers and types are given as S-Num and S-Type, respectively. S-Num and S-Type shall be one 
octet. The COPS Length field shall be two octets. Additional COPS objects are defined for use by IPCablecom 
Multimedia in the following clauses. 
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6.4.2.1 TransactionID 



TransactionID is a 2-byte unsigned integer quantity, which contains a token that is used by the AppHcation Manager to 
match responses from the Policy Server and by the Policy Server to match responses from the CMTS to the previous 
requests. The TransactionID shall also contain the command type that identifies the action to be taken or response. The 
TransactionID Object shall conform to the following format. 



Length = 8 


S-Num = 1 |S-Type = 1 


Transaction Identifier 


Gate Command Type 



The Transaction Identifier shall be set to when included in a Gate-Report-State message. 

Gate Command Type is a 2-byte unsigned integer value which identifies the Gate Control message type and shall be 
one of the following: 



<Reserved> 


1-3 


Gate-Set 


4 


Gate-Set-Ack 


5 


Gate-Set-Err 


6 


Gate-Info 


7 


Gate-Info-Ack 


8 


Gate-Info-Err 


9 


Gate-Delete 


10 


Gate-Delete-Ack 


11 


Gate-Delete-Err 


12 


<Reserved> 


13 


<Reserved> 


14 


Gate-Report-State 


15 


Gate-Cmd-Err 


16 


PDP-Config 


17 


PDP-Config-Ack 


18 


PDP-Config-Err 


19 


Synch-Request 


20 


Synch-Report 


21 


Synch-Complete 


22 


Msg-Receipt 


23 
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6.4.2.2 AMID 



AMID, the Application Manager ID, consists of two fields, the Application Manager Tag and Application Type. The 
Application Manager Tag is a 2-byte unsigned integer value which identifies the Application Manager responsible for 
handling the session. The Application Type is a 2-byte unsigned integer value which identifies the type of application 
that this gate is associated with. The Application Manager shall include this object in all messages it issues to the Policy 
Server. The Policy Server shall include the received AMID in all messages it issues down to the CMTS in response to 
the messages it receives from the Application Manager. The CMTS shall include the received AMID object in all 
messages it issues to the Policy Server, and likewise, the Policy Server shall include the received AMID to the 
Application Manager. The Policy Server may use the AMID in messages from the CMTS to resolve the Application 
Manager to which it may need to generate a message. 

Application Type is used by an Application Manager to identify the application that a gate is associated with. There is 
only one reserved value, zero, which indicates that there is "no defined application association". An Application 
Manager may pass a non-zero value to the Policy Server to indicate the particular application that a gate is associated 
with. The Policy Server may use this value when applying policies to this gate. The CMTS may use this value when 
performing admission control for this gate. The Application Type values are configured by the service provider in the 
Application Managers and Policy Servers. In order for the CMTS to utilize the Application Type in its admission 
control logic, the service provider would need to configure the CMTS with the allowed Application Types and their 
associated meaning. These values are unique within the domain of the service provider, and have context only within 
this domain. Therefore a single Application Manager that is servicing multiple service providers may be configured 
with a different Application Type for each service provider, for the same application. 

The AMID object shall conform to the following format. 



Length = 8 


S-Num = 2 IS-Type = 1 


Application Type 


Application Manager Tag 



6.4.2.3 SubscriberlD 

There are two different versions of the SubscriberlD object which differ in the IP version of the addresses that they 
contain. The simply named SubscriberlD object contains a 4-byte value giving the IPv4 address (represented as four 
concatenated octet values) of the subscriber for this service request. The IPv6SubscriberID object contains a 16-byte 
value giving the IPv6 address for this request. This IPv4 or IPv6 address may be the actual IP address of the subscriber 
CPE device requesting service (if this address is routable and visible from the head-end) or this address may be the IP 
address of the CM serving this subscriber (if NAT is performed behind the CM). In the message definitions provided 
elsewhere in the present document the term SubscriberlD refers generically to either a SubscriberlD object containing 
an IPv4 address or an IPv6SubscriberID object containing an IPv6 Address. This object is used to route Gate Control 
messages within a complex network of PS and CMTS elements. It may also be used in the definition and enforcement 
of per-subscriber policy rules. The same value of SubscriberlD provided by the PDP in the initial gate-set message for 
the gate shall be used in all subsequent Gate-Set, Gate-Info, and Gate-Delete messages submitted by the PDP for that 
gate. The SubscriberlD object shall conform to the following format. 



Length = 8 |S-Num = 3 |S-Type = 1 



SubscriberlD (4-octet IPv4 Address) 



The IPv6SubscriberID object shall conform to the following format. 



Length = 20 |S-Num = 3 |S-Type = 2 



Subscriberl p { 1 6-octet I Pv6 Address) 



6.4.2.4 GatelD 

GatelD is a 4-byte unsigned integer value which identifies the Gate referenced in the command message, or referenced 
by the CMTS for a response message. The CMTS shall ensure the GatelD is unique. If the CMTS also supports 
IPCablecom 1.x, the GatelD shall not duplicate a IPCablecom 1.x GatelD currently in use. The GatelD object shall 
conform to the following format. 
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Length = 8 



S-Num = 4 



|S-Type = 1 



Gate ID 



6.4.2.5 



GateSpec 



GateSpec defines a specific set of attributes associated with a Gate. The GateSpec object shall conform to the following 
format. 



Length = 16 


S-Num = 5 


S-Type = 1 


Flags IDSCP/TOS Field 


DSCP/TOS Mask 


SessionClassID 


Timer T1 


Timer T2 


Timer T3 


Timer T4 



Flag is a 1-byte bit-field value defined as follows: 

Bit 0: Direction bit, shall be either zero for a downstream Gate, or one for an upstream Gate. 

Bit 1: DSCP/TOS enable bit, shall be either zero to disable DSCP overwrite, or one to enable. 

Bits 2-7: Reserved, shall be zero. 

The same value of the direction bit provided by the PDF in the initial Gate-Set message shall be used in all subsequent 
Gate-Set messages submitted by the PDF for that gate. 

SessionClassID is a 1-byte unsigned integer value which identifies the proper admission control policy or parameters to 
be applied for this Gate. The SessionClassID is a bit field, defined as follows: 

Bit 0-2: Priority, a number from to 7, where is low priority and 7 is high. 

Bit 3: Preemption, set to enable preemption of bandwidth allocated to lower priority sessions if necessary 
(if supported). 

Bit 4-7: Configurable, default to 0. 

The priority field describes the relative importance of the session as compared to other sessions generated by the same 
PDP. The PEP may use this value to both implement priority based admission (in conjunction with the Preemption bit), 
and to defend the resulting flow from being preempted (see RFC 2751 [i.l] "defending priority"). The priority 
granularity of a CMTS may be smaller than the 8 available values. In this case the CMTS should distribute its levels 
across the entire priority range. For example, if the CMTS defines 2 priority levels, then it should interpret values to 3 
as low priority and values 4 to 7 as high priority. The Policy Server should normalize or otherwise transform this value 
to ensure a coherent priority system across the operator's CMTSs, but respond to any AM requests with the original 
priority value. 

The preemption bit is used to by a PDP to direct the PEP to apply a priority-based admission control. Preemption 
support is optional; a PEP may ignore this bit. If preemption is not requested by the PDP or not implemented by the 
PEP, then admission control policy will be on a first-come, first-served basis. If the PEP decides to preempt, it shall 
preempt bandwidth from sessions whose priority is lower than this session's priority, beginning with the lowest priority 
session(s). This bit is not used to control which sessions are preemptable; instead an unpreemptable session is requested 
by using the highest priority. If a lower priority session is terminated as a result of preemption, the PEP shall send a 
Gate-Report-State message to the PDP with a GateState object Reason field of 1- "Close initiated by CMTS due to 
reservation reassignment" and transition the gate to the "end" state. 

Application Managers that provide novel services may use the Configurable field to specify new session classes. The 
Policy Server may support configurable policies based on this value and may rewrite this field before forwarding the 
message to the CMTS. A CMTS may implement a novel session class metric using these bits, but the value shall map 
to a reasonable default for a PDP that is uninterested in this metric. 

The DSCP/TOS Field is a 1-byte bit field [7] defined by the following alternative structures, depending upon network 
management strategy. This field, combined with the 1-byte DSCP/TOS Mask, is used to identify particular bits within 
the IPv4 DSCP/TOS byte. 
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12 3 4 5 


6 


7 


Differentiated Services Code Point (DSCP) 


Not Used 


Not Used 




1 2 


3 1 4 1 5 1 6 


7 


IP Precedence 


IPTOS 


Not Used 



If the "Enable" bit in the GateSpec Flags field is set, then the CMTS shall mark the packets traversing the CMTS 
DSCP/TOS value. If the "Enable" bit is cleared, then the CMTS shall not perform any marking. 

Timers Tl, T2, T3, and T4 are 2-byte unsigned integers specified in seconds, and shall be used as outlined in the Gate 
Transition Diagram as described in clause 6.2. A value of zero for Tl indicates that the CMTS provisioned value for the 
timer shall be used. T2 corresponds to the DOCSIS Admitted timer and T3 corresponds to the DOCSIS Active timer. 
All corresponding DOCSIS requirements apply to these timers. Specifically, a zero value for either of these timers 
indicates that the corresponding timer shall be disabled. 



6.4.2.6 



Classifiers 



There are three types of classifiers supported in the present document. An Application Manager shall use either the 
Classifier, Extended Classifier, or IPv6 Classifier objects in accordance with clause 6.1.5. 

The Classifier object specifies the packet matching rules associated with a Gate. As defined in clauses 6.4.3.1 and 
6.4.3.2, for Unicast Gates multiple Classifier objects may be included in the Gate-Set to allow for complex classifier 
rules. When an AM is using Classifier objects, at least one Classifier shall be provided by the PDF in all Gate-Set 
messages. More than one Classifier is allowed for Unicast Gates. Only one classifier is required to be supported for 
Multicast Gates. Unlike DOCSIS DSx signalling. Classifiers have no identifier and have no explicit add, change, or 
remove operations. The entire set of Classifiers present in a Gate-Set message replaces the entire set of classifiers for 
the existing Gate. Equivalence of Classifiers is determined by comparing all fields within the Classifier. Classifiers may 
be provided in any order. 

The Classifier object shall conform to the following format. 



Lengtii = 24 



S-Num = 6 



S-Type = 1 



Protocol ID 



DSCP/TOS Field 



DSCP/TOS Mask 



Source IP Address (4-octets) 



Destination IP Address (4-octets) 



Source Port 



Destination Port 



Priority 



Reserved 



The Extended Classifier object also specifies the packet matching rules associated with a Gate, but includes more 
detailed information for matching traffic, as well adding, modifying, deleting, activating and inactivating Classifiers. As 
defined in clauses 6.4.3.1 and 6.4.3.2, for Unicast Gates multiple Extended Classifier objects may be included in the 
Gate-Set to allow for complex classifier rules. However, since the ordering of objects in a message and the order of 
processing those objects is not mandated, an AM should not send a GateSet with multiple Extended Classifiers with the 
same ClassifierlD, yet different Actions. When an AM is using Extended Classifier objects, at least one Extended 
Classifier shall be provided by the PDP in all Gate-Set messages. For Unicast Gates, more than one Extended Classifier 
is allowed. For Multicast Gates, only one Extended Classifier is required to be supported. Since the Extended Classifier 
is based on the DOCSIS IP Classifier, all DOCSIS classifier semantics apply, with the exception that at least one 
Extended Classifier be present in a Gate-Set message. 
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The Extended Classifier object shall conform to the following format. 



Length = 40 


S-Num = 6 


S-Type = 2 


Protocol ID 


DSCP/TOS Field 


DSCP/TOS Mask 


IP Source Address (4-octets) 


IP Source Mask (4-octets) 


IP Destination Address (4-octets) 


IP Destination Mask (4-octets) 


Source Port Start 


Source Port End 


Destination Port Start 


Destination Port End 


ClassifierlD 


Priority 


Activation State 


Action Reserved 



IP Source Address is a 4-octet IPv4 address, conforming to clause C.2. of [1], or zero for no match (i.e. a wildcard 
specification that will match any packet). 

For the Extended Classifier, the IP Source Mask is 4-octet IPv4 mask, conforming to IPv4 Source Mask clause C.2 of 
[1]. When the IP Source Address is zero, the IP Source Mask is irrelevant. When the IP Source Address is non-zero, 
only packets with source IP address "pkt.ip-src" will match if (pkt.ip-src AND classifier.ipmask-src) == classifier.ip-src. 

IP Destination Address is a 4-octet IPv4 address, conforming to the IPv4 Destination Address clause C.2 of [1], or zero 
for no match (i.e. a wildcard specification that will match any packet). 

For the Extended Classifier, the IP Destination Mask is 4-octet IPv4 mask, conforming to clause C.2 of [1]. When the 
IP Destination Address is zero, the IP Destination Mask is irrelevant. When the IP Destination Address is non-zero, 
only packets with destination IP address "pkt.ip-dst" will match if (pkt.ip-dst AND classifier.ipmask-dst) == 
classifier.ip-dst. 

For the Classifier object. Source Port and Destination Port shall be a pair of 2-byte unsigned integer values, or zero for 
no match. 

For the Extended Classifier object, the Source Port Start specifies the low-end TCP/UDP source port value and 
conforms to clause C.2 of [1]. Source Port End specifies the high-end TCP/UDP source port value and conforms to 
clause C.2 of [1]. An IP packet with TCP/UDP source port value "src-port" matches if Source Port 
Start < src-port < Source Port End. Likewise, the Destination Port Start specifies the low-end TCP/UDP destination port 
value and conforms to clause C.2 of [1]. Destination Port End specifies the high-end TCP/UDP destination port value 
and conforms to clause C.2 of [1]. An IP packet with TCP/UDP destination port value "dst-port" matches if Destination 
Port Start < dst-port < Destination Port End. When using the Source Port or Destination Port ranges, a Port Start = and 
Port End = 65535 represents a wildcarded port classification. 

Protocol ID shall conform to clause C.2 of [1], or zero for no match. 

DSCP/TOS Field is a 1-byte bit field which shall conform to the following alternative structures. 



1 1 1 2 1 3 1 4 1 5 


6 


7 


Differentiated Services Code Point (DSCP) 


Not Used 


Enable 




1 1 1 2 


3 1 4 1 5 1 6 


7 


IP Precedence 


IPTOS 


Enable 



DSCP/TOP Mask is a 1-byte bit field providing a bit mask used to select relevant bits from the accompanying 
DSCP/TOP Field value. 

If the "Enable" bit is set, then the CMTS shall use these values to construct the IP TOS Range and Mask field specified 
in its DSx messaging. If the "Enable" bit is cleared, then the CMTS shall omit the IP TOS Range and Mask values from 
its DSx messaging and exclude the IP TOS byte from the packet classification process. 
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The IPv6 Classifier object also specifies the packet matching rules associated with a Gate, when IPv6 Addresses are 
used. As defined in clauses 6.4.3.1 and 6.4.3.2, for Unicast Gates multiple IPv6 Classifier objects may be included in 
the Gate-Set to allow for complex classifier rules. However, since the ordering of objects in a message and the order of 
processing those objects is not mandated, an AM should not send a GateSet with multiple IPv6 Classifiers with the 
same ClassificationlD, yet different Actions. When an AM is using IPv6 Classifier objects, at least one IPv6 Classifier 
shall be provided by the PDP in all Gate-Set messages. For Unicast Gates more than one IPv6 Classifier is allowed. For 
Multicast Gates only one IPv6 Classifier is required to be supported. Since the IPv6 Classifier is based on the DOCSIS 
IPv6 Classifier, all DOCSIS classifier semantics apply, with the exception that at least one IPv6 Classifier be present in 
a Gate-Set message. 

The IPv6 Classifier object shall conform to the following format. 



Length = 64 


S-Num = 6 


S-Type = 3 


Reserved Flags tc-low 


tc-high 


tc-mask 


Flow Label 


Next Header Type 


Source Prefix Length 


Destination Prefix Length 


IPv6 Source Address (^ 6-octets} 








IPv6 Destination Address (16-octets] 








Source Port Start 


Source Port End 


Destination Port Start 


Destination Port End 


ClassifierlD 


Priority 


Activation State 


Action Reserved 



For the IPv6 Classifier, the Traffic Class Range and Mask fields, tc-low, tc-high, and tc-mask, allow matching on the 
IPv6 Traffic Class value. An IPv6 packet with IPv6 Traffic Class value "ip-tc" matches this parameter if tc-low < (ip-tc 
AND tc-mask) < tc-high. If the tc-mask field is set to 0, then comparison of the IPv6 packet Traffic Class byte for this 
entry is irrelevant. 

NOTE: The value Ox3F for tc-mask will exclude the Explicit Congestion Notification [i.3] bits from the 

comparison, and hence will result in classification based on DSCP [7]. For further discussion of the IPv6 
Traffic Class Range and Mask fields, refer to clause C.2 of [1]. 

For the IPv6 Classifier, Flag is a 4-bit field. The least significant bit is the Flow Label flag. When the Flow Label field 
contains valid data for comparison with the IPv6 Flow Label, this flag shall be set to 1 . When comparison of the IPv6 
Flow Label for this entry is irrelevant then the Flow Label flag shall not be set (value = 0). When the Flow Label flag is 
set to 0, the CMTS shall not include the IPv6 Flow Label field in the classifier. All other flags shall be set to zero. 

For the IPv6 Classifier, the Flow Label field matches the Flow Label used in the IPv6 header. The 20 least significant 
bits represent the 20-bit IPv6 Flow Label while the 12 most significant bits are ignored. For further discussion of the 
IPv6 Flow Label field, refer to clause C.2 of [1]. 

For the IPv6 Classifier, the value of the Next Header Type field specifies the desired next header type value for any 
header or extension header associated with the packet. Typically this value will specify the next layer protocol type. 
There are two special IPv6 next header type field values: "256" matches traffic with any IPv6 next header type value, 
and "257" matches both TCP and UDP traffic. Values greater than 257 are invalid for comparisons (i.e. no traffic can 
match this entry). For further discussion of the IPv6 Next Header Type field, refer to clause C.2 of [1]. 

For the IPv6 Classifier, the value of the Source Prefix Length field specifies the fixed, most significant bits of an IPv6 
address that are used to determine address range and subnet ID for the IPv6 Source Address. For further discussion of 
the IPv6 Source Prefix Length field, refer to clause C.2 of [1]. 

For the IPv6 Classifier, the value of the Destination Prefix Length field specifies the fixed, most significant bits of an 
IPv6 address that are used to determine address range and subnet ID for the IPv6 Destination Address. For further 
discussion of the IPv6 Destination Prefix Length field, refer to clause C.2 of [1]. 
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For the IPv6 Classifier, the value of the IPv6 Source Address field specifies the matching value for the IPv6 source 
address. An IPv6 packet with IPv6 source address "ip6-src" matches this parameter if src = (ip6-src AND smask). 
"smask" is computed by setting the most significant "n" bits of smask to 1, where "n" is IPv6 Source Prefix Length in 
bits. If the IPv6 Source Address parameter is set to 0, then comparison of the IPv6 packet source address for this entry 
is irrelevant. For further discussion of the IPv6 Source Address field, refer to clause C.2 of [1]. 

For the IPv6 Classifier, the value of the IPv6 Destination Address field specifies the matching value for the IPv6 
destination address. An IPv6 packet with IPv6 destination address "ip6-dst" matches this parameter if dst = (ip6-dst 
AND dmask). "dmask" is computed by setting the most significant "n" bits of dmask to 1, where "n" is IPv6 Destination 
Prefix Length in bits. If the IPv6 Destination Address parameter is set to 0, then comparison of the IPv6 packet 
destination address for this entry is irrelevant. For further discussion of the IPv6 Destination Address field, refer to 
clause C.2 of [1]. 

Priority is a 1-byte field that allows differentiation between classifiers that might overlap. A default value of 64 should 
be used if a specific priority value is not required. For further discussion of the Priority field, refer to clause C.2 of [1]. 

For the Extended Classifier or the IPv6, the ClassifierlD is a 2 byte unsigned integer which is used as an identifier for 
the Extended Classifier. This value shall be unique per Gate. The Application Manager assigns the ClassifierlD. 

For the Extended Classifier or the IPv6, the Activation State is a 1 byte unsigned integer with the following values: 

0x00 Inactive 

0x01 Active 

All other values are reserved. If a value other than or 1 is used by the AM, the CMTS shall generate a Gate-Set-Err 
with IPCablecom Error 17 (Invalid Field Value in Object) and Error-Subcode of 6 I 2 (S-Num I S-Type). When the 
Activation State is set to (Inactive) the classifier shall not be used to match traffic. When set to 1 (Active), the 
classifier shall be used to match traffic. 

For the Extended Classifier or the IPv6, the Action field is a 1 byte unsigned integer with the following values: 

0x00 Add classifier 

0x01 Replace classifier 

0x02 Delete classifier 

0x03 No change 

All other values are reserved. If a value other than 0, 1, 2, or 3 is used by the AM, the CMTS shall generate a Gate-Set- 
Err, with IPCablecom Error 17 (Invalid Field Value in Object) and Error-Subcode of 6 I 2 (S-Num I S-Type). The 
Action field is meant to assist the CMTS with managing the list of classifiers associated with a Gate. 

When the Action is set to (Add classifier) by the AM, the classifier will be added to the list of classifiers for the Gate. 
If the Action field is set to (Add classifier) for a ClassifierlD currently being used for this Gate, the CMTS shall 
generate a Gate-Set-Err with IPCablecom Error 17 (Invalid Field Value in Object) and Error-Subcode of 6 I 2 
(S-Num I S-Type). 

When set to 1 (Replace classifier) by the AM, the classifier matching the ClassifierlD specified will be replaced with 
the information in the Extended Classifier object. If the Action field is set to 1 (Replace classifier) with a ClassifierlD 
not known to the CMTS, the CMTS shall generate a Gate-Set-Err with IPCablecom Error 17 (Invalid Field Value in 
Object) and Error-Subcode of 6 I 2 (S-Num I S-Type). 

When set to 2 (Delete classifier) by the AM, the classifier matching the ClassifierlD will be removed from the list of 
classifiers for the Gate. If the Action field is set to 2 (Delete classifier) with a ClassifierlD not known to the CMTS, the 
CMTS shall generate a Gate-Set-Err with IPCablecom Error 17 (Invalid Field Value in Object) and Error-Subcode of 6 I 
2 (S-Num I S-Type). 

When set to 3 (No Change) by the AM, the CMTS will leave the classifier matching the ClassifierlD unmodified. This 
action is technically the same as not sending the Extended Classifier for the ClassifierlD at all, however, this method 
shall be used when the AM only has a single classifier for a Gate and needs to modify the Gate. This is due to the fact 
that every Gate-Set must contain at least one classifier. If the Action field is set to 3 (No Change) with a ClassifierlD 
not known to the CMTS, the CMTS shall generate a Gate-Set-Err with IPCablecom Error 17 (Invalid Field Value in 
Object) and Error-Subcode of 6 I 2 (S-Num I S-Type). 
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The CMTS shall only use the value of 3 (No change) in a Gate-Info- Ack, and is considered the default value of this 
field. 

6.4.2.7 Traffic Profiles 

There are four different ways to express a traffic profile. The traffic profile can be expressed via a FlowSpec, a DOCSIS 
Service Class Name, DOCSIS-specific parameters or Upstream Drop. The four methods are distinguished via a 
different S-Type value in the Traffic Profile (S-Num = 7) object. S-Type of 1 indicates the object contains a traffic 
profile specified in RSVP FlowSpec format. S-Type of 2 indicates the object contains a traffic profile specified in 
DOCSIS Service Class Name format. S-Type of 3 - 8 indicates the object contains a traffic profile that is specified via 
DOCSIS-specific parameters. S-Type of 9 indicates the object contains a traffic profile specified in an Upstream Drop 
format. 

All Traffic Profiles utilize "replace" semantics, meaning that the envelopes present in this Traffic Profile replace all 
existing envelopes associated with the Gate and corresponding Service Flow. Thus, all traffic parameters associated 
with a given Gate shall be included in every message that includes a Traffic Profile. The traffic profile format (RSVP 
FlowSpec, DOCSIS Service Class Name, DOCSIS-specific parameters. Upstream Drop) for a specific envelope shall 
remain constant and unchanged throughout the life of the gate. 

All Traffic Profiles share a common field known as the Envelope Field. This field is a bit field that signals the envelope 
types (i.e. Authorized, Reserved, and Committed) that are present in the object. A value of 1 in a given bit field 
indicates that the envelope type is present in the Traffic Profile. 

• Bit 0: Authorized Envelope 

• Bit 1 : Reserved Envelope 

• Bit 2: Committed Envelope 

Thus a bit pattern of 001 (or 0x01) indicates the presence of only the Authorized Envelope, while a value of 1 1 1 (or 
0x7) indicates the presence of all three envelopes. Only the following values are legal: 001, Oil and 111; the Envelope 
Field shall be set to one of these three legal values. Further limitations on the value of the Envelope Field may be a 
function of the current state of the Gate. Refer to clause 6.2 for more information. 

For the Traffic Profile formats that allow multiple sets of envelope parameters, the mapping of envelope parameter sets 
follows one of the following methods: 

• If all of the envelope types that are indicated in the envelope field share a common set of envelope parameters, 
then the PDP should ensure that exactly one set of envelope parameters are present in the traffic profile. This 
allows for the most efficient transmission and processing of the Traffic Profile throughout the system. 

• Otherwise, the PDP shall ensure that exactly one set of envelope parameters is included for each of the 
envelope types that are indicated in the envelope field. The proper order of the envelope parameter sets is 
shown in the appropriate message diagram in clauses 6.4.2.1 and 6.4.2.3 thru 6.4.2.7.8. 

While all Traffic Profiles end up providing QoS on the access network, it is important to note several subtle differences 
between the signalling mechanisms. As noted previously, the conversion of a FlowSpec (S-Type 1) to DOCSIS 
parameters by the CMTS is generally less efficient than specifying the DOCSIS parameters themselves. That said, 
specifying DOCSIS parameters explicitly (S-Types 3-7) is not a panacea either, the QoS MIB only logs QoS 
information about named Service Flows in its ServiceFlowLogTable. Thus, only flows created via S-Type 2 will have 
logged QoS information in this table. For some this may not be a major issue, but for debugging and just general 
operational tracking this subtlety should be taken into account by operators and Application Manager vendors 
evaluating the Traffic Profile signalling alternatives provided by the present document. 

6.4.2.7.1 FlowSpec 

The FlowSpec object defines the Traffic Profile associated with a Gate through an RSVP -like parameterization scheme. 
The mapping of these parameters to DOCSIS parameters is specified in clause 8. The FlowSpec object shall conform to 
the following specification. 
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Length = 36 or 64 or 92 



S-Num = 7 



S-Type = 1 



Envelope | Service Number 



Reserved 



Reserved 



Authorized Envelope 



Token Bucket Rate [r] (IEEE floating point number) 



Token Bucket Size [b] (IEEE floating point number) 



Peak Data Rate (p) (IEEE floating point number) 



Minimum Policed Unit [m] (integer) 



Maximum Packet Size [M] (integer) 



Rate [R] (IEEE floating point number) 



Slack Term [S] (integer) 



Reserved Envelope (optional) 



Token Bucket Rate [r] (IEEE floating point number) 



Token Bucket Size [b] (IEEE floating point number) 



Peak Data Rate (p) (IEEE floating point number) 



Minimum Policed Unit [m] (integer) 



Maximum Packet Size [M] (integer) 



Rate [R] (IEEE floating point number) 



Slack Term [S] (integer) 

Committed Envelope (optional) 

Token Bucket Rate [r] (IEEE floating point number) 



Token Bucket Size [b] (IEEE floating point number) 



Peak Data Rate (p) (IEEE floating point number) 



Minimum Policed Unit [m] (integer) 



Maximum Packet Size [M] (integer) 



Rate [R] (IEEE floating point number) 



Slack Term [S] (integer) 

The Service Number field corresponds to the RSVP FlowSpec service number as defined in [4]. If Service Number is 
set to five, this indicates Controlled Load service and the CMTS shall utilize only the TSpec values (i.e. token bucket 
parameters) to perform the necessary authorization, reservation and commit operations. For Controlled Load service, 
the CMTS shall ignore the RSpec R and S fields. 

If Service Number is set to two, this signals Guaranteed service and the CMTS shall utilize both the TSpec and RSpec 
values to perform the necessary authorization, reservation and commit operations. 

The values r, b, p, m, M, R, and s are defined and described in clause 9. 
6.4.2.7.2 DOCSIS Service Class Name 

The DOCSIS Service Class Name object defines the preconfigured Service Class Name associated with a Gate. The 
DOCSIS Service Class Name object shall conform to the following specification. 



Length = 1 2 or 1 6 or 20 or 24 


S-Num = 7 


S-Type = 2 


Envelope Reserved 


Reserved 


Reserved 


Service Class Name 







The Service Class Name is shall be 2-16 bytes of null-terminated ASCII string. (Refer to clause C.2 of [1]). This name 
shall be padded with null bytes to align on a 4-byte boundary. 

Note that unlike a FlowSpec Traffic Profile which allows for different parameters to be associated with each Envelope, 
the DOCSIS Service Class Name Traffic Profile supports different Gate states as specified by the Envelope field, but 
each Envelope is defined by the same associated DOCSIS Service Class Name. This allows for having two-phase 
commit operations utilizing the DOCSIS Service Class Names, but each Envelope must be identical. Also note, that it is 
possible to change the DOCSIS Service Class Name associated with a Gate, but that such a change applies to all 
Envelopes associated with a given Gate. 
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6.4.2.7.3 Best Effort Service 



The Best Effort object defines the Traffic Profile associated with a Gate through an upstream DOCSIS-specific 
parameterization scheme. The Best Effort object shall conform to the following specification. 



Length = 44, 80 or 116 



S-Num = 7 



S-Type = 3 



Envelope [Reserved 



Reserved 



Reserved 



Authorized Envelope 



Traffic Priority Reserved 



Request Transmission Policy 



Maximum Sustained Traffic Rate 



Maximum Traffic Burst 



linimum Reserved Traffic Rate 



Assumed Minimum Reserved Traffic Rate Packet Size Maximum Concatenated Burst 



Required Attribute Mask 



Forbidden Attribute Mask 



Attribute Aggregation Rule Mask 



Reserved Envelope (optional) 



Traffic Priority Reserved 



Request Transmission Policy 



Maximum Sustained Traffic Rate 



Maximum Traffic Burst 



linimum Reserved Traffic Rate 



Assumed Minimum Reserved Traffic Rate Packet Size Maximum Concatenated Burst 



Required Attribute Mask 



Forbidden Attribute Mask 



Attribute Aggregation Rule Mask 



Committed Envelope (optional] 



Traffic Priority Reserved 



Request Transmission Policy 



Maximum Sustained Traffic Rate 



Maximum Traffic Burst 



linimum Reserved Traffic Rate 



Assumed Minimum Reserved Traffic Rate Packet Size Maximum Concatenated Burst 



Required Attribute Mask 



Forbidden Attribute Mask 



Attribute Aggregation Rule Mask 

Traffic Priority is a 1-byte unsigned integer field specifying the relative priority assigned to the Service Flow in 
comparison with other flows. This field is fully defined in the Traffic Priority clause of [1]. A default Traffic Priority of 
should be used if a specific Traffic Priority value is not required. 

Request/Transmission Policy is a 4-byte bit field as defined in clause C.2 of [1]. A default Request/Transmission policy 
of should be used if a specific Request/Transmission Policy value is not required. 

Maximum Sustained Traffic Rate is a 4-byte unsigned integer field specifying the rate parameter, in bits/sec, for [1]. A 
value of indicates that no explicitly-enforced Maximum Sustained Rate is requested. A default Maximum Sustained 
Traffic Rate of should be used if a specific Maximum Sustained Traffic Rate is not required. 

Maximum Traffic Burst is a 4-byte unsigned integer field specifying the token bucket size, in bytes, for a token-bucket- 
based rate limit for this Service Flow. This field is fully defined in clause C.2 of [1]. A default Maximum Traffic Burst 
of 3 044 bytes should be used if a specific Maximum Traffic Burst is not required. The value of this parameter has no 
effect unless a non-zero value has been provided for the Maximum Sustained Traffic Rate parameter. 

Minimum Reserved Traffic Rate is a 4-byte unsigned integer field specifying the minimum rate, in bits/sec, reserved for 
this Service Flow. This field is fully defined in clause C.2 of [1]. A default Minimum Reserved Traffic Rate of should 
be used if a specific Minimum Reserved Traffic Rate is not required. 

Assumed Minimum Reserved Traffic Rate Packet Size is a 2-byte unsigned integer field specifying an assumed 
minimum packet size, in bytes, for which the Minimum Reserved Traffic Rate will be provided for this flow. This field 
is fully defined in clause C.2 of [1]. A default Assumed Minimum Reserved Traffic Rate Packet Size of should be 
used if a specific Assumed Minimum Reserved Traffic Rate Packet size is not required. Upon receipt of a value of the 
CMTS shall utilize its implementation-specific default size for this parameter, not bytes. 
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Maximum Concatenated Burst is a 2-byte unsigned integer specifying the maximum concatenated burst (in bytes) 
which a Service Flow is allowed. This field is fully defined in clause C.2 of [1]. A value of means there is no limit. A 
default Maximum Concatenated Burst of 1 522 bytes should be used if a specific Maximum Concatenated Burst is not 
required. 

Attribute Masks define a specific set of attributes associated with a DOCSIS 3.0 service flow. The CMTS shall ignore 
the bonded bit in the Required and Forbidden Attribute Mask objects if the cable modem associated with the service 
flow is operating in pre-3.0 DOCSIS mode. The Required Attribute Mask limits the set of channels and bonding groups 
to which the CMTS assigns the service flow by requiring certain attributes. This field is fully defined in clause C.2 of 
[1]. The Forbidden Attribute Mask limits the set of channels and bonding groups to which the CMTS assigns the service 
flow by forbidding certain attributes. This field is fully defined in clause C.2 of [1]. The CMTS is free to assign the 
service flow to any channel that satisfies the traffic profile if no channel is available that satisfies the Required Attribute 
Mask and Forbidden Attribute Mask for the service flow. The Attribute Aggregation Rule Mask provides guidance to 
the CMTS as to how it might use the attribute masks of individual channels to construct a dynamic bonding group for 
this service flow. This field is fully described in clause "Service Flow Attribute Aggregation Rule Mask" of [1]. As 
described in that clause a default Attribute Aggregation Rule Mask of should be used if specific Attribute Aggregation 
Rules are not required. 

6.4.2.7.4 Non-Real-Time Polling Service 

The Non-Real Time Polling object defines the Traffic Profile associated with an upstream Gate through a 
DOCSIS -specific parameterization scheme. The Non-Real Time Polling object shall conform to the following 
specification. 



Length = 48, 88 or 128 



S-Num = 7 



S-Type = 4 



Envelope [Reserved 



Reserved 



Reserved 



Authorized Envelope 



Traffic Priority [Reserved 



Request Transmission Policy 



Maximum Sustained Traffic Rate 



Maximum Traffic Burst 



linimum Reserved Traffic Rate 



Assumed Minimum Reserved Traffic Rate Packet Size Maximum Concatenated Burst 



Nominal Polling Interval 



Required Attribute Mask 



Forbidden Attribute Mask 



Attribute Aggregation Rule Mask 



Reserved Envelope (optional) 



Traffic Priority [Reserved 



Request Transmission Policy 



Maximum Sustained Traffic Rate 



Maximum Traffic Burst 



linimum Reserved Traffic Rate 



Assumed Minimum Reserved Traffic Rate Packet Size Maximum Concatenated Burst 



Nominal Polling Interval 



Required Attribute Mask 



Forbidden Attribute Mask 



Attribute Aggregation Rule Mask 



Committed Envelope (optional) 



Traffic Priority [Reserved 



Request Transmission Policy 



Maximum Sustained Traffic Rate 



Maximum Traffic Burst 



linimum Reserved Traffic Rate 



Assumed Minimum Reserved Traffic Rate Packet Size Maximum Concatenated Burst 



Nominal Polling Interval 



Required Attribute Mask 



Forbidden Attribute Mask 



Attribute Aggregation Rule Mask 
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Traffic Priority is a 1-byte unsigned integer field specifying the relative priority assigned to the Service Flow in 
comparison with other flows. This field is fully defined in clause C.2 of [1]. A default Traffic Priority of should be 
used if a specific Traffic Priority value is not required. 

Request/Transmission Policy is a 4-byte bit field as defined in clause C.2 of [1]. 

NOTE: For this Service Flow Scheduling Type there is no default value for Request/Transmission Policy and all 
values (including 0) have meaning in DOCSIS. 

Maximum Sustained Traffic Rate is a 4-byte unsigned integer field specifying the rate parameter, in bits/sec, for a 
token-bucket-based rate limit for this Service Flow. This field is fully defined in clause C.2 of [1]. A value of 
indicates that no explicitly-enforced Maximum Sustained Rate is requested. A default Maximum Sustained Traffic Rate 
of should be used if a specific Maximum Sustained Traffic Rate is not required. 

Maximum Traffic Burst is a 4-byte unsigned integer field specifying the token bucket size, in bytes, for a token-bucket- 
based rate limit for this Service Flow. This field is fully defined in clause C.2 of [1]. A default Maximum Traffic Burst 
of 3 044 bytes should be used if a specific Maximum Traffic Burst is not required. The value of this parameter has no 
effect unless a non-zero value has been provided for the Maximum Sustained Traffic Rate parameter. 

Minimum Reserved Traffic Rate is a 4-byte unsigned integer field specifying the minimum rate, in bits/sec, reserved for 
this Service Flow. This field is fully defined in clause C.2 of [1]. A default Minimum Reserved Traffic Rate of should 
be used if a specific Minimum Reserved Traffic Rate is not required. 

Assumed Minimum Reserved Traffic Rate Packet Size is a 2-byte unsigned integer field specifying an assumed 
minimum packet size, in bytes, for which the Minimum Reserved Traffic Rate will be provided for this flow. This field 
is fully defined in clause C.2 of [1]. A default Assumed Minimum Reserved Traffic Rate Packet Size of should be 
used if a specific Assumed Minimum Reserved Traffic Rate Packet size is not required. Upon receipt of a value of the 
CMTS shall utilize its implementation-specific default size for this parameter, not bytes. 

Maximum Concatenated Burst is a 2-byte unsigned integer specifying the maximum concatenated burst (in bytes) 
which a Service Flow is allowed. This field is fully defined in clause C.2 of [1]. A value of means there is no limit. A 
default Maximum Concatenated Burst of 1 522 bytes should be used if a specific Maximum Concatenated Burst is not 
required. 

Nominal Polling Interval is a 4-byte unsigned integer field specifying the nominal interval (in units of microseconds) 
between successive unicast request opportunities for this Service Flow on the upstream channel. This field is fully 
defined in clause C.2 of [1]. A default Nominal Polling Interval of should be used if a specific Nominal Polling 
Interval is not required. Upon receipt of a value of the CMTS shall utilize its implementation-specific default size for 
this parameter - not microseconds. 

Attribute Masks define a specific set of attributes associated with a DOCSIS 3.0 service flow. The CMTS shall ignore 
the bonded bit in the Required and Forbidden Attribute Mask objects if the cable modem associated with the service 
flow is operating in pre-3.0 DOCSIS mode. The Required Attribute Mask limits the set of channels and bonding groups 
to which the CMTS assigns the service flow by requiring certain attributes. This field is fully defined in clause C.2 of 
[1]. The Forbidden Attribute Mask limits the set of channels and bonding groups to which the CMTS assigns the service 
flow by forbidding certain attributes. This field is fully defined in clause C.2 of [1]. The CMTS is free to assign the 
service flow to any channel that satisfies the traffic profile if no channel is available that satisfies the Required Attribute 
Mask and Forbidden Attribute Mask for the service flow. The Attribute Aggregation Rule Mask provides guidance to 
the CMTS as to how it might use the attribute masks of individual channels to construct a dynamic bonding group for 
this service flow. This field is fully described in clause "Service Flow Attribute Aggregation Rule Mask" of [1]. As 
described in that clause a default Attribute Aggregation Rule Mask of should be used if specific Attribute Aggregation 
Rules are not required. 

6.4.2.7.5 Real-Time Polling Service 

The Real-Time Polling object defines the Traffic Profile associated with an upstream Gate through a DOCSIS-specific 
parameterization scheme. The Real-Time Polling object shall conform to the following specification. 
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Length = 48, 88or 128 




S-Num = 7 


S-Type = 5 


Envelope Reserved 


Reserved 


Reserved 


Authorized Envelope 


Request Transmission Policy 


Maximum Sustained Traffic Rate 


Maximum Traffic Burst 



Minimum Reserved Traffic Rate 

Assumed Minimum Reserved Traffic Rate Packet Size [Maximum Concatenated Burst 

Nominal Polling Interval 

Tolerated Poll Jitter 

Required Attribute Mask 

Forbidden Attribute Mask 

Attribute Aggregation Rule Mask 

Reserved Envelope (optional) 

Request Transmission Policy 



Maximum Sustained Traffic Rate 



Maximum Traffic Burst 



Minimum Reserved Traffic Rate 



Assumed Minimum Reserved Traffic Rate Packet Size Maximum Concatenated Burst 

Nominal Polling Interval 



Tolerated Poll Jitter 

Required Attribute Mask 

Forbidden Attribute Mask 

Attribute Aggregation Rule Mask 



Committed Envelope (optional) 



Request Transmission Policy 



Maximum Sustained Traffic Rate 



Maximum Traffic Burst 



Minimum Reserved Traffic Rate 



Assumed Minimum Reserved Traffic Rate Packet Size Maximum Concatenated Burst 



Nominal Polling Interval 

Tolerated Poll Jitter 

Required Attribute Mask 

Forbidden Attribute Mask 

Attribute Aggregation Rule Mask 



Request/Transmission Policy is a 4-byte bit field as defined in clause C.2 of [1]. 

NOTE: For this Service Flow Scheduling Type there is no default value for Request/Transmission Policy and all 
values (including 0) have meaning in DOCSIS. 

Maximum Sustained Traffic Rate is a 4-byte unsigned integer field specifying the rate parameter, in bits/sec, for a 
token-bucket-based rate limit for this Service Flow. This field is fully defined in clause C.2 of [1]. A value of 
indicates that no explicitly-enforced Maximum Sustained Rate is requested. A default Maximum Sustained Traffic Rate 
of should be used if a specific Maximum Sustained Traffic Rate is not required. 

Maximum Traffic Burst is a 4-byte unsigned integer field specifying the token bucket size, in bytes, for a token-bucket- 
based rate limit for this Service Flow. This field is fully defined in clause C.2 of [1]. A default Maximum Traffic Burst 
of 3 044 bytes should be used if a specific Maximum Traffic Burst is not required. The value of this parameter has no 
effect unless a non-zero value has been provided for the Maximum Sustained Traffic Rate parameter. 

Minimum Reserved Traffic Rate is a 4-byte unsigned integer field specifying the minimum rate, in bits/sec, reserved for 
this Service Flow. This field is fully defined in clause C.2 of [1]. A default Minimum Reserved Traffic Rate of should 
be used if a specific Minimum Reserved Traffic Rate is not required. 

Assumed Minimum Reserved Traffic Rate Packet Size is a 2-byte unsigned integer field specifying an assumed 
minimum packet size, in bytes, for which the Minimum Reserved Traffic Rate will be provided for this flow. This field 
is fully defined in clause C.2 of [1]. A default Assumed Minimum Reserved Traffic Rate Packet Size of should be 
used if a specific Assumed Minimum Reserved Traffic Rate Packet size is not required. Upon receipt of a value of the 
CMTS shall utilize its implementation-specific default size for this parameter, not bytes. 

Maximum Concatenated Burst is a 2-byte unsigned integer specifying the maximum concatenated burst (in bytes) 
which a Service Flow is allowed. This field is fully defined in clause C.2 of [1]. A value of means there is no limit. A 
default Maximum Concatenated Burst of 1 522 bytes should be used if a specific Maximum Concatenated Burst is not 
required. 
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Nominal Polling Interval is a 4-byte unsigned integer field specifying the nominal interval (in units of microseconds) 
between successive unicast request opportunities for this Service Flow on the upstream channel. This field is fully 
defined in clause C.2 of [1]. For this Service Flow Scheduling Type there is no default value for Nominal Polling 
Interval. 

Tolerated Polling Jitter is a 4-byte unsigned integer field specifying the maximum amount of time that the unicast 
request interval may be delayed from the nominal periodic schedule (measured in microseconds). This field is fully 
defined in clause C.2 of [1]. The minimum non-zero allowed value is 800 jis. If the CMTS receives a Gate-Set message 
with Tolerated Polling Jitter not equal to zero and less than 800 jJ,s, the CMTS shall reply with a Gate-Set-Err message 
with a IPCablecom Error-Code of "Invalid Field Value in Object". A default Tolerated Polling Jitter of should be used 
if a specific Tolerated Polling Jitter is not required. Upon receipt of a value of the CMTS shall utilize its 
implementation-specific default size for this parameter - not microseconds. If the Tolerated Polling Jitter is set to in 
a gate, the CMTS shall return the value of in any Gate-Info-Ack message for that gate. 

Attribute Masks define a specific set of attributes associated with a DOCSIS 3.0 service flow. The CMTS shall ignore 
the bonded bit in the Required and Forbidden Attribute Mask objects if the cable modem associated with the service 
flow is operating in pre-3.0 DOCSIS mode. The Required Attribute Mask limits the set of channels and bonding groups 
to which the CMTS assigns the service flow by requiring certain attributes. This field is fully defined in clause C.2 of 
[I]. The Forbidden Attribute Mask limits the set of channels and bonding groups to which the CMTS assigns the service 
flow by forbidding certain attributes. This field is fully defined in clause C.2 of [1]. The CMTS is free to assign the 
service flow to any channel that satisfies the traffic profile if no channel is available that satisfies the Required Attribute 
Mask and Forbidden Attribute Mask for the service flow. The Attribute Aggregation Rule Mask provides guidance to 
the CMTS as to how it might use the attribute masks of individual channels to construct a dynamic bonding group for 
this service flow. This field is fully described in clause "Service Flow Attribute Aggregation Rule Mask" of [1]. As 
described there a default Attribute Aggregation Rule Mask of should be used if specific Attribute Aggregation Rules 
are not required. 

6.4.2.7.6 Unsolicited Grant Service 

The Unsolicited Grant object defines the Traffic Profile associated with an upstream Gate through a DOCSIS-specific 
parameterization scheme. The Unsolicited Grant object shall conform to the following specification. 



Length = 36, 64 or 92 



S-Num = 7 



S-Type = 6 



Envelope [Reserved 



Reserved 



Reserved 



Authorized Envelope 



Request Transmission Policy 



Unsolicited Grant Size Grants/Interval Reserved 



Nominal Grant Interval 



Tolerated Grant Jitter 



Required Attribute Mask 



Forbidden Attribute Mask 



Attribute Aggregation Rule Mask 



Reserved Envelope (optional) 



Request Transmission Policy 



Unsolicited Grant Size Grants/Interval Reserved 



Nominal Grant Interval 



Tolerated Grant Jitter 



Required Attribute Mask 



Forbidden Attribute Mask 



Attribute Aggregation Rule Mask 



Committed Envelope (optional) 



Request Transmission Policy 



Unsolicited Grant Size Grants/Interval Reserved 



Nominal Grant Interval 



Tolerated Grant Jitter 



Required Attribute Mask 



Forbidden Attribute Mask 



Attribute Aggregation Rule Mask 

Request/Transmission Policy is a 4-byte bit field as defined in clause C.2 of [1]. 
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NOTE: For this Service Flow Scheduling Type there is no default value for Request/Transmission Policy and all 
values (including 0) have meaning in DOCSIS. 

Bit 9 in the Request/Transmission Policy enables/disables the use of segment headers. A segment header is 8 bytes in 
length. It shall be accounted for in the Unsolicited Grant Size parameter when segment header usage is enabled. The 
CMTS shall ignore Bit 9 in the Request/Transmission Policy if the cable modem associated with the service flow is 
operating in DOCSIS 1.1 or 2.0 mode. For more information on segment headers and their use please see clause 6.3 of 
[1]. 

Unsolicited Grant Size is a 2-byte unsigned integer field specifying the grant size (in bytes) as defined in clause C.2 of 
[1]. There is no default value of Unsolicited Grant Size. 

Grants per Interval is a 1-byte unsigned integer field specifying the number of grants per Nominal Grant Interval as 
defined in clause C.2 of [1]. There is no default value of Grants per Interval, but a value of 1 is recommended. 

Nominal Grant Interval is a 4-byte unsigned integer field specifying the nominal time between successive data grant 
opportunities for this Service Flow (in units of microseconds) as defined in clause C.2 of [1]. 

Tolerated Grant Jitter is a 4-byte unsigned integer field specifying the maximum amount of time that transmission 
opportunities may be delayed from the nominal periodic schedule (in units of microseconds) as defined in clause C.2 of 
[1]. The minimum allowed value is 800 jis. If the CMTS receives a Gate-Set message with Tolerated Grant Jitter less 
than 800 ]ls, the CMTS shall reply with a Gate-Set-Err message with a IPCablecom Error-Code of "Invalid Field Value 
in Object". There is no default value of Nominal Grant Interval. There is no default value for Tolerated Grant Jitter. 

Attribute Masks define a specific set of attributes associated with a DOCSIS 3.0 service flow. The CMTS shall ignore 
the bonded bit in the Required and Forbidden Attribute Mask objects if the cable modem associated with the service 
flow is operating in pre-3.0 DOCSIS mode. The Required Attribute Mask limits the set of channels and bonding groups 
to which the CMTS assigns the service flow by requiring certain attributes. This field is fully defined in clause C.2 of 
[1]. The Forbidden Attribute Mask limits the set of channels and bonding groups to which the CMTS assigns the service 
flow by forbidding certain attributes. This field is fully defined in clause C.2 of [1]. The CMTS is free to assign the 
service flow to any channel that satisfies the traffic profile if no channel is available that satisfies the Required Attribute 
Mask and Forbidden Attribute Mask for the service flow. The Attribute Aggregation Rule Mask provides guidance to 
the CMTS as to how it might use the attribute masks of individual channels to construct a dynamic bonding group for 
this service flow. This field is fully described in clause "Service Flow Attribute Aggregation Rule Mask" of [1]. As 
described in that clause, a default Attribute Aggregation Rule Mask of should be used if specific Attribute 
Aggregation Rules are not required. 

6.4.2.7.7 Unsolicited Grant Service with Activity Detection 

The Unsolicited Grant with Activity Detection object defines the Traffic Profile associated with an upstream Gate 
through a DOCSIS -specific parameterization scheme. The Unsolicited Grant with Activity Detection object shall 
conform to the following specification. 



Length = 44, 80 or 116 



S-Num = 7 



S-Type = 7 



Envelope [Reserved 



Reserved 



Reserved 



Authorized Envelope 



Request Transmission Policy 



Unsolicited Grant Size Grants/Interval Reserved 



Nominal Grant Interval 



Tolerated Grant Jitter 



Nominal Polling Interval 



Tolerated Poll Jitter 



Required Attribute Mask 



Forbidden Attribute Mask 



Attribute Aggregation Rule Mask 



Reserved Envelope (optional) 



Request Transmission Policy 



Unsolicited Grant Size Grants/Interval Reserved 



Nominal Grant Interval 



Tolerated Grant Jitter 



Nominal Polling Interval 
Tolerated Poll Jitter 
Required Attribute Mask 
Forbidden Attribute Mask 



£75/ 



58 



ETSI TS 102 879 V1.1.1 (2010-06) 



Attribute Aggregation Rule Mask 



Committed Envelope (optional] 



Request Transmission Policy 



Unsolicited Grant Size 



Grants/Interval 



Reserved 



Nominal Grant Interval 



Tolerated Grant Jitter 



Nominal Polling Interval 



Tolerated Poll Jitter 



Required Attribute Mask 



Forbidden Attribute Mask 



Attribute Aggregation Rule Mask 



Request/Transmission Policy is a 4-byte bit field as defined in clause C.2 of [1]. 

NOTE: For this Service Flow Scheduling Type there is no default value for Request/Transmission Policy and all 
values (including 0) have meaning in DOCSIS. 

Bit 9 in the Request/Transmission Policy enables/disables the use of segment headers. A segment header is 8 bytes in 
length. It shall be accounted for in the Unsolicited Grant Size parameter when segment header usage is enabled. The 
CMTS shall ignore Bit 9 in the Request/Transmission Policy if the cable modem associated with the service flow is 
operating in DOCSIS 1.1 or 2.0 mode. For more information on segment headers and their use please see clause 6.3 of 
[1]. 

Unsolicited Grant Size is a 2-byte unsigned integer field specifying the grant size (in bytes) as defined in clause C.2 of 
[1] There is no default value of Unsolicited Grant Size. 

Grants per Interval is a 1-byte unsigned integer field specifying the number of grants per Nominal Grant Interval as 
defined in clause C.2 of [1]. There is no default value of Grants per Interval, but a value of 1 is recommended. 

Nominal Grant Interval is a 4-byte unsigned integer field specifying the nominal time between successive data grant 
opportunities for this Service Flow (in units of microseconds) as defined in clause C.2 of [1]. There is no default value 
of Nominal Grant Interval. 

Tolerated Grant Jitter is a 4-byte unsigned integer field specifying the maximum amount of time that transmission 
opportunities may be delayed from the nominal periodic schedule (in units of microseconds) as defined in u clause C.2 
of [1]. The minimum allowed value is 800 jJ,s. If the CMTS receives a Gate-Set message with Tolerated Grant Jitter less 
than 800 |J,s, the CMTS shall reply with a Gate-Set-Err message with a IPCablecom Error-Code of "Invalid Field Value 
in Object". There is no default value of Tolerated Grant Jitter. 

Nominal Polling Interval is a 4-byte unsigned integer field specifying the nominal interval (in units of microseconds) 
between successive unicast request opportunities for this Service Flow on the upstream channel. This field is fully 
defined in clause C.2 of [1]. There is no default value of Nominal Polling Interval. 

Tolerated Polling Jitter is a 4-byte unsigned integer field specifying the maximum amount of time that the unicast 
request interval may be delayed from the nominal periodic schedule (measured in microseconds). This field is fully 
defined in clause C.2 of [1]. The minimum non-zero allowed value is 800 jis. If the CMTS receives a Gate-Set message 
with Tolerated Polling Jitter not equal to zero and less than 800 jis, the CMTS shall reply with a Gate-Set-Err message 
with a IPCablecom Error-Code of "Invalid Field Value in Object". Upon receipt of a value of the CMTS shall utilize 
its implementation-specific default size for this parameter, not microseconds. 

Attribute Masks define a specific set of attributes associated with a DOCSIS 3.0 service flow. The CMTS shall ignore 
the bonded bit in the Required and Forbidden Attribute Mask objects if the cable modem associated with the service 
flow is operating in pre-3.0 DOCSIS mode. The Required Attribute Mask limits the set of channels and bonding groups 
to which the CMTS assigns the service flow by requiring certain attributes. This field is fully defined in clause C.2 of 
[1]. The Forbidden Attribute Mask limits the set of channels and bonding groups to which the CMTS assigns the service 
flow by forbidding certain attributes. This field is fully defined in clause C.2 of [1]. The CMTS is free to assign the 
service flow to any channel that satisfies the traffic profile if no channel is available that satisfies the Required Attribute 
Mask and Forbidden Attribute Mask for the service flow. The Attribute Aggregation Rule Mask provides guidance to 
the CMTS as to how it might use the attribute masks of individual channels to construct a dynamic bonding group for 
this service flow. This field is fully described in clause "Service Flow Attribute Aggregation Rule Mask" of [1]. As 
described in that clause a default Attribute Aggregation Rule Mask of should be used if specific Attribute Aggregation 
Rules are not required. 
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6.4.2.7.8 Downstream Service 



The Downstream object defines the Traffic Profile associated with a Gate through a downstream DOCSIS-specific 
parameterization scheme. The Downstream object shall conform to the following specification. 



Length = 48, 88 or 128 



S-Num = 7 S-Type = 8 



Envelope Reserved 

Authorized Envelope 

Traffic Priority [Downstream Resequencing [Reserved 



Reserved Reserved 



Maximum Sustained Traffic Rate 



Maximum Traffic Burst 



Minimum Reserved Traffic Rate 



Assumed Minimum Reserved Traffic Rate Packet Size Reserved 



Maximum Downstream Latency 
Downstream Peak Traffic Rate 



Required Attribute Mask 



Forbidden Attribute Mask 



Attribute Aggregation Rule Mask 



Reserved Envelope (optional] 



Traffic Priority [Downstream Resequencing [Reserved 



Maximum Sustained Traffic Rate 



Maximum Traffic Burst 



linimum Reserved Traffic Rate 



Assumed Minimum Reserved Traffic Rate Packet Size 



Maximum Downstream Latency 



Downstream Peak Traffic Rate 



Required Attribute Mask 



Forbidden Attribute Mask 



Attribute Aggregation Rule Mask 



Committed Envelope (optional) 



Traffic Priority [Downstream Resequencing [Reserved 



Maximum Sustained Traffic Rate 



Maximum Traffic Burst 



linimum Reserved Traffic Rate 



Assumed Minimum Reserved Traffic Rate Packet Size Reserved 



Maximum Downstream Latency 



Downstream Peak Traffic Rate 



Required Attribute Mask 



Forbidden Attribute Mask 



Attribute Aggregation Rule Mask 

Traffic Priority is a 1-byte unsigned integer field specifying the relative priority assigned to the Service Flow in 
comparison with other flows. This field is fully defined in clause C.2 of [1]. A default Traffic Priority of should be 
used if a specific Traffic Priority value is not required. 

Downstream Resequencing is a 1-byte unsigned integer field specifying the use of sequence numbers in downstream 
DOCSIS 3.0 service flows. This field is fully defined in clause C.2 of [1]. The CMTS shall honour the requested 
Downstream Resequencing operation for all Gate requests. It is possible that the CMTS may receive conflicting 
downstream resequencing direction by the AM for Multicast Gate requests (e.g. multiple Multicast Gate requests for the 
same Multicast destination but with different downstream resequencing operation). In such a case the CMTS shall either 
honour the Multicast Gate request or reject it with error code 35 (Multicast Gate Downstream Resequencing mismatch). 
For a Multicast Gate, the CMTS shall ignore the Downstream Resequencing object if the cable modem associated with 
the service flow is operating in MDF disabled mode. The CMTS shall ignore the Downstream Resequencing object if 
the cable modem associated with the service flow is operating in pre-3.0 DOCSIS mode. DOCSIS 3.0 introduced the 
concept of downstream channel bonding where the CMTS can simultaneously transmit on multiple channels. 
Downstream channels may not all have the same amount of latency such that two packets scheduled simultaneously by 
the CMTS may not arrive simultaneously at the cable modem. The CMTS can insert sequence numbers in each 
DOCSIS packet header to allow the cable modem to re-order out of sequence packets. The cable modem will hold 
higher numbered packets while waiting for lower numbered packets to arrive. The maximum wait time is 18ms. 
Applications that can tolerate lost packets or applications that cannot tolerate packet latency of up to 18ms can disable 
the use of sequence numbers by setting the Downstream Resequencing value to 1 . 
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Maximum Sustained Traffic Rate is a 4-byte unsigned integer field specifying the rate parameter, in bits/sec, for a 
token-bucket-based rate limit for this Service Flow. This field is fully defined in clause C.2 of [1]. A value of 
indicates that no explicitly-enforced Maximum Sustained Rate is requested. A default Maximum Sustained Traffic Rate 
of should be used if a specific Maximum Sustained Traffic Rate is not required. 

Maximum Traffic Burst is a 4-byte unsigned integer field specifying the token bucket size, in bytes, for a token-bucket- 
based rate limit for this Service Flow. This field is fully defined in clause C.2 of [1]. A default Maximum Traffic Burst 
of 3 044 bytes should be used if a specific Maximum Traffic Burst is not required. The value of this parameter has no 
effect unless a non-zero value has been provided for the Maximum Sustained Traffic Rate parameter. 

Minimum Reserved Traffic Rate is a 4-byte unsigned integer field specifying the minimum rate, in bits/sec, reserved for 
this Service Flow. This field is fully defined in clause C.2 of [1]. A default Minimum Reserved Traffic Rate of should 
be used if a specific Minimum Reserved Traffic Rate is not required. 

Assumed Minimum Reserved Traffic Rate Packet Size is a 2-byte unsigned integer field specifying an assumed 
minimum packet size, in bytes, for which the Minimum Reserved Traffic Rate will be provided for this flow. This field 
is fully defined in clause C.2 of [1]. A default Assumed Minimum Reserved Traffic Rate Packet Size of should be 
used if a specific Assumed Minimum Reserved Traffic Rate Packet size is not required. Upon receipt of a value of the 
CMTS shall utilize its implementation-specific default size for this parameter, not bytes. 

Maximum Downstream Latency is a 4-byte unsigned integer field specifying the maximum latency between reception 
of a packet on the CMTS's NSI and the forwarding of the packet on its RF interface as defined in clause C.2 of [1]. A 
default Maximum Downstream Latency of should be used if a specific Maximum Downstream Latency is not 
required. Upon receipt of a value of 0, the CMTS shall not include this parameter in its DOCSIS signalling for this 
Service Flow. 

Downstream Peak Traffic Rate is a 4-byte unsigned integer field, specifying the rate parameter P of a token-bucket- 
based peak rate limiter for packets of a downstream service flow. Configuring this peak rate parameter permits an 
operator to define a Maximum Burst value for the Downstream Maximum Sustained Rate much larger than a maximum 
packet size, but still limit the burst of packets consecutively transmitted for a service flow. The Downstream Peak 
Traffic Rate parameter is fully defined in clause C.2 of [1]. The CMTS shall not include this parameter in its DOCSIS 
signalling for this service flow if a value of is supplied, if the cable modem for which the Gate applies is not 
provisioned in DOCSIS 3.0 mode, or if the CMTS does not support the enforcement of this value. 

Attribute Masks define a specific set of attributes associated with a DOCSIS 3.0 service flow. The CMTS shall ignore 
the bonded bit in the Required and Forbidden Attribute Mask objects if the cable modem associated with the service 
flow is operating in pre-3.0 DOCSIS mode. The Required Attribute Mask limits the set of channels and bonding groups 
to which the CMTS assigns the service flow by requiring certain attributes. This field is fully defined in clause C.2 of 
[1]. The Forbidden Attribute Mask limits the set of channels and bonding groups to which the CMTS assigns the service 
flow by forbidding certain attributes. This field is fully defined in clause C.2. of [1]. The CMTS is free to assign the 
service flow to any channel that satisfies the traffic profile if no channel is available that satisfies the Required Attribute 
Mask and Forbidden Attribute Mask for the service flow. The Attribute Aggregation Rule Mask provides guidance to 
the CMTS as to how it might use the attribute masks of individual channels to construct a dynamic bonding group for 
this service flow. This field is fully described in clause "Service Flow Attribute Aggregation Rule Mask" of [1]. As 
described in that clause a default Attribute Aggregation Rule Mask of should be used if specific Attribute Aggregation 
Rules are not required. 



6.4.2.7.9 



Upstream Drop 



The Upstream Drop object defines the Traffic Profile associated to a Gate with a null service flow. The Upstream Drop 
object shall conform to the following specification. 



Length = 8 


S-Num = 1 


S-Type = 9 


Envelope = 7 Reserved 


Reserved 


Reserved 
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DOCSIS 3.0 [1] clause 7.5.1.2.2 details the CMTS and CM procedures when a Upstream Drop Traffic Profile is 
received from the AM via the PS. 

An Upstream Drop object only applies to gates in the committed state; as a result, the AM shall set the envelope of an 
Upstream Drop object to commit (7). If the CMTS receives an Upstream Drop object with an envelope other than 
commit (7), the CMTS shall return IPCablecom Error 12 (Incompatible Envelope) to the AM. When the CMTS realizes 
the Upstream Drop object is destined to a CM that does not support DOCSIS 3.0 or has UDC disabled, the CMTS shall 
return a Gate-Set-Err with IPCablecom Error 27 (Upstream Drop Unsupported) to the AM. 

Since the Upstream Drop object represents a null service flow at the CM, the state timers managed by the CMTS are not 
applicable. As a result, the AM shall disable (set value to 0) the state timers Tl, T2, T3 and T4. If the CMTS receives a 
value other than for these timers, the CMTS shall return IPCablecom Error 17 (Invalid Field Value in Object) to the 
AM. 

6.4.2.8 Event Generation Info 

The Event Generation Info object contains all the information necessary to support the event messages as specified and 
required in [14]. The IPv4 Event Generation Info object is used when the RKS Addresses are specified in IPv4 format, 
whereas the IPv6 Event Generation Info object is used when the RKS Addresses are specified in IPv6 format. Both 
Primary and Secondary RKS addresses shall be specified using the same IP version. 

The IPv4 Event Generation Info object shall conform to the following specification. 



Length = 44 |S-Num = 8 |S-Type = 1 



Primary-Record-Keeping-Server-IP-Address (4-octets) 



Primary-Record-Keeping-Server-Port [Reserved 



Secondary-Record-Keeping-Server-IP-Address (4-octets) 



Secondary-Record-Keeping-Server-Port | Reserved 



BiJling_-_Correlation-J p (24-_bytesj 



Primary-Record-Keeping-Server-IP- Address is a 4-byte field which shall contain the IPv4 address of the primary RKS 
to whom event records are to be sent. 

Primary-Record-Keeping-Server-Port field is a 2-byte unsigned integer which shall contain the port number on the 
primary RKS where event records are to be sent. 

Secondary-Record-Keeping-Server-IP-Address is a 4-byte field which shall contain the IPv4 address of the secondary 
RKS to whom records are to be sent if the primary RKS is unavailable. 

Secondary-Record-Keeping-Server-Port is a 2-byte unsigned integer which shall contain the port number on the 
secondary RKS where event records are to be sent. 

Billing-Correlation-ID is a 24-byte field which shall contain the identifier assigned by the AM or PS for all records 
related to this session. See [14] for the definition and format of this attribute. 

The IPv6 Event Generation Info object shall conform to the following specification. 
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Length = 68 |S-Num = 8 |S-Type = 2 



PrinnarY-Record-Keepin£-Server-IPv6-Address (1 6-octets) 



Primary-Record-Keeping-Server-Port [Reserved 



SecondarY^Record-Keeping-Seryer-JPye-Address (1 6^^ 



Secondary-Record-Keeping-Server-Port [Reserved 



BilJing:Cprrel_atioP:lP_ (2_4-bytes) 



Primary-Record-Keeping-Server-IPv6- Address is a 16-byte field which shall contain the IPv6 address of the primary 
RKS to whom event records are to be sent. 

Primary-Record-Keeping-Server-Port field is a 2-byte unsigned integer which shall contain the port number on the 
primary RKS where event records are to be sent. 

Secondary-Record-Keeping-Server-lPv6- Address is a 16-byte field which shall contain the IPv6 address of the 
secondary RKS to whom records are to be sent if the primary RKS is unavailable. 

Secondary-Record-Keeping-Server-Port is a 2-byte unsigned integer which shall contain the port number on the 
secondary RKS where event records are to be sent. 

Billing-Correlation-ID is a 24-byte field which shall contain the identifier assigned by the AM or PS for all records 
related to this session. See [14] for the definition and format of this attribute. 

6.4.2.9 Volume-Based Usage Limit 

The Volume-Based Usage Limit object specifies the amount of data that can be transmitted over this Gate before 
meeting a volume threshold. This object is OPTIONAL in every Gate-Set message. It shall be provided by the PEP in 
Gate-Info- Ack messages if it has been provided by the PDP in any Gate-Set message. It shall not be provided in Gate- 
Info-Ack messages if it has not been provided by the PDP by any Gate-Set message. It shall not be used in any other 
messages. The Volume-Based Usage Limit object shall conform to the following specification. 



Lengths 12 [S-Num = 9 [S-Type = 1 



Usage Umit 



Usage Limit is a 8-byte unsigned integer defined in units of kilobytes (1 kilobyte = 1 024 bytes). A value of zero 
indicates no volume limit is imposed. The bytes counted towards the limit are from the byte after the DOCSIS MAC 
Header HCS to the end of the CRC for all packets transmitted on the Service Flow associated with this Gate. 

6.4.2.10 Time-Based Usage Limit 

The Time-Based Usage Limit object specifies the amount of time a Gate can remain committed before meeting a time 
limit threshold. The Time-Based Usage Limit object shall conform to the following specification. 



Lengtii = 8 [S-Num = 10 [S-Type = 1 



Time Limit 
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Time Limit is a 4-byte unsigned integer defined in units of seconds. This is the Hmit on the amount of time a Gate can 
be in a committed state. This object is OPTIONAL in every Gate-Set message. If included in a Gate-Set this object shall 
be stored by the CMTS. It shall be provided by the PEP in Gate-Info- Ack messages if it has been provided by the PDP 
in any Gate-Set message. It shall not be provided in Gate-Info- Ack messages if it has not been provided by the PDP by 
any Gate-Set message. While the Application Manager is ultimately responsible for Gates associated with a media 
session that has exceeded its Time-Based Usage Limit, the CMTS or Policy Server may use this object to police 
Application Manager enforcement of Time-Based Usage Limit policies established by the operator. The Application 
Manager or Policy Server may also query for this object as part of a failure recovery or other mechanism. 

A value of zero indicates no time limit for the associated Gate. 

6.4.2.11 Opaque Data 

The Opaque Data object contains information that a Policy Server or Application Manager may store on a CMTS that 
remains opaque to the CMTS. The opaque data object is OPTIONAL in every Gate-Set message. It shall not be used in 
any other messages issued by the PDP to the PEP. If the object has been defined by a successfully acknowledged Gate- 
Set message, the CMTS shall store the Opaque Data locally. If Opaque Data has been defined, it shall be returned by 
the CMTS in all appropriate acknowledgement, and Gate-Report-State messages. If the object has not been defined it 
shall not be provided in acknowledgement, error, and Gate-Report-State messages. The Opaque Data object uses 
replace semantics, i.e. if the Opaque Data object has already been defined for a Gate, and a new Opaque Data object is 
received in a subsequent Gate-Set message for that Gate, the Opaque Data object in the subsequent Gate-Set message 
shall replace the Opaque Data object currently being stored on the CMTS. 

If the Opaque Data object is included in a Gate-Set message from the Application Manager to a Policy Server, the 
Policy Server shall forward this object to the CMTS. The length of the Opaque Data is fixed at 8 bytes. 



Length = 12 |S-Num = 11 |S-Type = 1 



Opaque Data 



6.4.2.12 Gate Time Info 

The Gate Time Info object contains the total amount of time the Gate has been in the Committed and Committed 
Recovery states. This counter shall be stopped upon the Gate transitioning out of the Committed or Committed 
Recovery states to either the Reserved state or Authorized state. If the Gate subsequently transitions back to the 
Committed state, this counter shall be restarted where it last stopped, i.e. when transitioning out of the Committed or 
Committed Recovery states. The Gate Time Info object shall conform to the following specification. 



Length = 8 |S-Num = 12 |S-Type = 1 



Time Committed 



Time Committed is a 4-byte unsigned integer indicating the number of seconds this Gate has been in either the 
Committed state or the Committed-Recovery state. 

NOTE: This is intended to be identical to docsQosServiceFlowTimeActive from the QOS MIB [8]. 

6.4.2.13 Gate Usage Info 

The Gate Usage Info object contains a counter indicating the number of kilobytes transmitted over this Gate. The Gate 
Usage Info object shall conform to the following specification. 



Length = 12 |S-Num = 13 |S-Type = 1 



Octet Count 



Octet Count is a 8-byte unsigned integer which represents the number of bytes (counted from the DOCSIS MAC 
Header HCS to the end of the CRC) which have traversed the Service Flow associated with the Gate in units of 
1 024 bytes. 
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6.4.2.14 



IPCablecom Error 



The IPCablecom Error object contains information on the type of error that has occurred. The error is generated in 
response to a Gate Control command and is contained in Gate-Set-Err, Gate-Info-Err and Gate-Delete-Err messages. 
The IPCablecom Error object shall conform to the following specification. 



Length = 8 


S-Nunn = 14 |S-Type = 1 


Error-Code 


Error-Subcode 



Error-Code is a 2-byte unsigned integer representing a specific error and shall be one of the following. 

Table 2: Error Codes 



Error 
Code 


Description 


Gate-Set- 
Err 


Gate-Del- 
Err 


Gate- 
Info-Err 


Gate- 
Cmd-Err 


PDP- 
Config-Err 


Synch- 
Complete 


1 


Insufficient Resources 


X 










X 


2 


Unknown GatelD 


X 


X 


X 








6 


IVIissing Required Object 


X 


X 


X 




X 


X 


7 


Invalid Object 


X 


X 


X 




X 


X 


8 


Volume Based Usage Limit 
Exceeded 


X 












9 


Time Based Usage Limit 
Exceeded 


X 












10 


Session Class Limit Exceeded 


X 












11 


Undefined Service Class Name 


X 












12 


Incompatible Envelope 


X 












13 


Invalid SubscriberlD 


X 


X 


X 






X 


14 


Unauthorized AMID 


X 


X 


X 






X 


15 


Number of Classifiers Not 
Supported 


X 












16 


Policy Exception 


X 












17 


Invalid Field Value in Object 


X 










X 


18 


Transport Error 


X 


X 


X 






X 


19 


Unknown Gate Command 








X 






20 


DOCSIS 1.0 CM 


X 












21 


Number of SIDs exceeded in CM 


X 












22 


Number of SIDs exceeded in 
CMTS 


X 












23 


Unauthorized PSID 


X 


X 


X 




X 


X 


24 


No State for PDP 












X 


25 


Unsupported Synch Type 












X 


26 


State Data Incomplete 












X 


27 


Upstream Drop Unsupported 


X 












28 


Multicast Gate Error 


X 












29 


Multicast Volume Limit 
Unsupported 


X 












30 


Uncommitted Multicast Not 
Supported 


X 












31 


Multicast Gate Modification Not 
Supported 


X 












32 


Upstream Multicast Not Supported 


X 












33 


Multicast GateSpec incompatibility 


X 













£75/ 



65 



ETSI TS 1 02 879 V1 .1 .1 (201 0-06) 



Error 
Code 


Description 


Gate-Set- 
Err 


Gate-Del- 
Err 


Gate- 
Info-Err 


Gate- 
Cmd-Err 


PDP- 
Config-Err 


Synch- 
Complete 


34 


Multicast QoS Error 


X 












35 


Multicast Downstream 
Resequencing mismatch 


X 












127 


Other, Unspecified Error 


X 


X 


X 




X 


X 



Error-Subcode is a 2-byte unsigned integer field used to provide further information about the error. In the case of 
Error-Codes 6, 7 and 17, this 16-bit field shall contain, as two 8-bit values the S-Num and S-Type of the object that is 
missing or in error. The order of the S-Num and S-Type values within the Error-Subcode shall be the same as in the 
original message. In cases where multiple valid alternatives exist for the S-Type of a missing object, this portion of the 
Error-Subcode shall be set to zero. In the case of Error-Code 15, the Error-Subcode field shall contain the number of 
Classifiers supported per Gate. In the case of Error-Code 16, the Error-Subcode is a specific value assigned by the 
Policy Server. The values contained within the Error-Subcode field for Error-Code 16 are vendor specific and are not 
defined by the present document. In the case of Error-Code 19, the Error-Subcode is the Gate Command Type value 
that was contained in the original TransactionID object. 

Error-Codes 8, 9, 10, and 16 are generated as a result of a Policy Request failing to meet the requirements of a Policy 
Server's authorization. When the Application Manager issues a Gate-Set message with a volume or time-based limit to 
the Policy Server, the Policy Server may reject the request with Error-Code 8 or 9 based on policy rules installed on the 
Policy Server. For example, such a policy rule may state that if a volume limit request exceeds a maximum value, the 
Policy Server must reject the request. Error-Code 10 may be used if a policy is defined limiting parameters within the 
SessionClassID, without mapping them to alternate values. Error-Code 16 may be used to convey other policy 
exceptions in the Error-SubCode parameter. Error-Code 18 may be generated by a PEP if the gate command message is 
discarded because of congestion, buffer overflows, or link outages. Error-Code 19 shall be generated by a PEP if the 
gate command message contains an unknown or invalid Gate Command Type value. 



6.4.2.15 



Gate State 



The information in the Gate State object reflects the current state of the Gate. The CMTS shall include the Gate State 
object in any unsolicited messages that it sends to the Policy Server. The Policy Server may use this information to 
report state to the Application Manager, or for enforcing complex rules that might require state knowledge of the Gate. 

Typically, the Policy Server is aware of state transitions since it usually provides the stimulus for these transitions to the 
CMTS, but in some cases the Gate may transition locally on the CMTS without the Policy Server's involvement. In 
these cases, the CMTS shall report the state transition to the Policy Server via unsolicited Gate-Report-State messages. 
When issuing Gate-Report-State messages, the PEP shall make sure the Solicited Flag in the COPS message header is 
cleared, and the Report Type in the header is set to Accounting. The Gate State object shall conform with the following 
specification. 



Length = 8 


S-Num = 15 |S-Type=1 


State 


Reason 



State is a 2-byte unsigned integer field which shall indicate one of the following states: 

1 = Idle/Closed 

2 = Authorized 

3 = Reserved 

4 = Committed 

5 = Committed-Recovery 

Reason is a 2-byte unsigned integer field which shall indicate one of the following reasons for this update: 

1 = Close initiated by CMTS due to reservation reassignment 

2 = Close initiated by CMTS due to lack of DOCSIS MAC-layer responses 

3 = Close initiated by CMTS due to timer Tl expiration 
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4 = Close initiated by CMTS due to timer T2 expiration 

5 = Inactivity timer expired due to Service Flow inactivity (timer T3 expiration) 

6 = Close initiated by CMTS due to lack of Reservation Maintenance 

7 = Gate state unchanged, but volume limit reached 

8 = Close initiated by CMTS due to timer T4 expiration 

9 = Gate state unchanged, but timer T2 expiration caused reservation reduction 

10 = Gate state unchanged, but time limit reached 

11= Close initiated by Policy Server or CMTS, volume limit reached 

12 = Close initiated by Policy Server or CMTS, time limit reached 

13 = Close initiated by CMTS, other 

14 = Gate state unchanged, but SharedResourcelD updated 

15 = Close initiated by CMTS due to loss of shared resource 
65535 = Other 

6.4.2.16 Version Info 

The Version Info object is used to enable Multimedia applications to adapt their interactions with other devices so that 
interoperability can be achieved between products supporting different protocol versions. Both the Major Version 
Number and the Minor Version Number are 2 byte unsigned integers. Both the PDP and the PEP must include this 
object as specified in clause 6.5.1. 



Length = 8 


S-Num = 16 |S-Type = 1 


Major Version Number 


Minor Version Number 



6.4.2.17 PSID 

PSID is a 4-byte unsigned integer value which uniquely identifies a Policy Server. The PSID number space is a subset 
of the AMID number space; therefore the PSID for a policy server shall also be unique among all the AMIDs that have 
been provisioned for Application Managers. The object shall be formatted as follows. 



Lengtii = 8 |S-Num = 17 |S-Type = 1 



PSID 



6.4.2.18 Synch Options 

The Synch Options object is used to specify the details of how synchronization should be performed when a PDP issues 
a synchronization request. The object shall be formatted as follows. 



Length = 8 


S-Num = 18 


S-Type = 1 


Reserved 


Report Type 


Synch Type 



Report Type is a 1-byte unsigned integer used to indicate the type of data that should be sent back in synchronization 
reports and shall be one of the following: 

= Standard Report Data 

1 = Complete Gate Data 
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Synch Type is a 1-byte unsigned integer used to indicate the type of synchronization that is being requested and shall be 
one of the following: 

= Full Synchronization 

1 = Incremental Synchronization 

6.4.2.19 Msg Receipt Key 

The Msg Receipt Key is a 32-bit unsigned integer value, and is assigned by the PEP. This object may be included in any 
message sent from a PEP to a PDP and when it is present it is an indication that the PEP is requesting that the PDP 
confirms that it received the message. There are no constraints on how the PEP assigns this value, and for that reason 
the PDP should not make any assumptions about how it is used. The object shall be formatted as follows. 



Length = 8 |S-Num = 19 |S-Type = 1 



Msg Receipt Key 



6.4.2.20 UserlD 

The UserlD is a UTF-8 string value that identifies the user associated with a gate. This object is optional, and may be 
associated with a gate by an AM when the gate is originally created. 

If the length (in bytes) of the string value is not a multiple of 4, then the value shall be padded with null bytes until the 
length is a multiple of 4. Unlike most of the other objects in the present document where the Length field does not 
change, the Length field in the UserlD object can vary. This field shall be set to 4 more than the length of the padded 
value to account for the header fields. 



Length = <Padded UserlD length> + 4 


|S-Num = 21 


IS-Type = 1 


UserlD 


... as needed 





6.4.2.21 SharedResourcelD 

The Shared Resource Identifier is a 4-byte unsigned integer value assigned by the CMTS for Multicast Gate requests. 
There are no constraints, other than being locally unique within the scope of the CMTS, on how the CMTS assigns this 
value, and for that reason the PS and/or AM should not make any assumptions about how it is used, other than to 
identify when the same resource is used to fulfil multiple Gate requests. 

The object shall be formatted as follows. 



Length = 8 |S-Num = 22 |S-Type = 1 



SharedResourcelD 



6.4.3 Gate Control Messages 



There are two separate profiles for Gate Control messages: one for messages exchanged between the Application 
Manager and the Policy Server, and one for messages between the Policy Server and the CMTS. While similar, these 
two profiles do exhibit some minor differences. 

The following statements describe the PCMM message formats, covering both COPS and PCMM objects. These 
statements specify the content of messages, but do not imply a particular ordering of objects within each message. In 
particular, any ordering of PCMM objects shall be accepted as valid (and may be generated), and the order of COPS 
objects shall be as specified in RFC 2748 [9]. Note that since PCMM objects only exist inside COPS objects, the 
distinction between these two sets is clear. This containment model also ensures that there are no issues with the relative 
order of COPS and PCMM objects. 
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6.4.3.1 Profile for Application Manager to Policy Server Interface 

Messages that perform gate control between the Application Manager and Policy Server are defined and shall be 
formatted as follows. 

Note that messages from the Application Manager to Policy Server shall be formatted as COPS Decision messages, and 
messages from Policy Server to Application Manager shall be formatted as COPS Report-State messages. 

<Client Open> = <COPS Common Header> <COPS PEPID> <ClientSI Info> 

<ClientSI Info> = <COPS Client SI Header> <iyiiyi Version Info> 

<Gate Control Command> = <COPS Common Header> <Client Handle> <Context> 

<Decision Flags> <ClientSI Data> 
<ClientSI Data> = <Gate-Set> | <Gate-Info> | <Gate-Delete> | 

<PDP-Config> | <Synch-Request> | <Msg-Receipt> 
<Gate Control Response> = <COPS Common Header> <Client Handle> <Report Type> 

<ClientSI Object> 
<ClientSI Object> = <Gate-Set-Ack> | <Gate-Set-Err> | <Gate-Info-Ack> | <Gate-Inf o-Err> | 
<Gate-Delete-Ack> | <Gate-Delete-Err> | <Gate-Report-State> 
<Gate-Cmd-Err> | 

<PDP-Conf ig-Ack> | <PDP-Conf ig-Err> | 
<Synch-Report> | <Synch-Complete> 
<Gate-Set> = <Decision Header> <TransactionID> <AMID> <SubscriberID> [<GateID>] 
<GateSpec> <Traffic Profile> <classifier> [<classif ier> . . . ] 
[<Event Generation Info>] 

[<Volume-Based Usage Limit>] [ <Time-Based Usage Limit> ] [<Opaque Data>] 
[<UserID>] 
<Gate-Set-Ack> = <ClientSI Header> <TransactionID> <AMID> <SubscriberID> <GateID> 
[<Opaque Data>] 
[<Msg- Receipt- Key >] 
[<SharedResourceID>] 
<Gate-Set-Err> = <ClientSI Header> <TransactionID> <AMID> <SubscriberID> 

<IPCablecom Error> [<Opaque Data>] [<Msg-Receipt-Key>] 
<Gate-Info> = <Decision Header> <TransactionID> <AMID> <SubscriberID><GateID> 
<Gate-Info-Ack> = <ClientSI Header> <TransactionID> <AMID> <SubscriberID> <GateID> 
[<Event Generation Info>] <GateSpec> <GateState> <classifier> 
[<classif ier . . . >] <Traffic Profile> [<UserID>] 

<Gate Time InfoxGate Usage Info> [<Volume-Based Usage Limit>] 
[<Time-Based Usage Limit>] [<Opaque Data>] 
[<Msg- Receipt- Key >] 
[<SharedResourceID>] 
<Gate-Info-Err> = <ClientSI Header> <TransactionID> <AMID> <GateID> <IPCablecom Err> 

[<Opaque Data>] [<Msg-Receipt-Key>] 
<Gate-Delete> = <Decision Header> <TransactionID> <AMID> <SubscriberID> <GateID> 
<Gate-Delete-Ack> = <ClientSI Header> <TransactionID> <AMID> <GateID> [<Opaque Data>] 

[<Msg- Receipt- Key >] 
<Gate-Delete-Err> = <ClientSI Header> <TransactionID> <AMID> <GateID> 

<IPCablecom Error> [<Opaque Data>] [<Msg-Receipt-Key>] 
<Gate-Report-State> = <ClientSI Header> <TransactionID> <AMID> 
<SubscriberID> <GateID> <GateState> 
<Gate Time Info> <Gate Usage Info> [<Opaque Data>] 
[<Msg- Receipt- Key >] 
[<SharedRe source ID >] 
<Gate-Cmd-Err> = <ClientSI Header> <TransactionID> <AMID> <IPCablecom Error> 
<PDP-Config> = <Decision Header> <TransactionID> <AMID> [<AMID>...] 
<PDP-Conf ig-Ack> = <ClientSI Header> <TransactionID> [<Msg-Receipt-Key>] 
<PDP-Conf ig-Err> = <ClientSI Header> <TransactionID> <IPCablecom Error> 

[<Msg- Receipt- Key >] 
<Synch-Request> = <Decision Header> <TransactionID> <AMID> [<SubscriberID>] 

<Synch Options> 
<Synch-Report> = <ClientSI Header> <TransactionID> <AMID> 
<SubscriberID> <GateID> <GateState> 
<Gate Time Info> <Gate Usage Info> [<Opaque Data>] 

[<GateSpec>] [<Traffic Profile>] [<classif ier...>] [<Event Generation Info>] 
[<Volume-Based Usage Limit>] [<Time-Based Usage Limit>] 
[<Msg-Receipt-Key>] [<UserID>] [<SharedResourceID>] 
<Synch-Complete> = <ClientSI Header> <TransactionID> <AMID> [<IPCablecom Error>] 

[<Msg- Receipt- Key >] 
<Msg-Receipt> = <Decision Header> <TransactionID> <Msg-Receipt-Key> 
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6.4.3.2 Profile for Policy Server to CMTS Interface 

Messages that perform Gate Control between the PoHcy Server and CMTS are defined and shall be formatted as 
follows. 

Note that messages from Policy Server to CMTS shall be formatted as COPS Decision messages, and messages from 
CMTS to Policy Server shall be formatted as COPS Report-State messages. 

<Client Open> = <COPS Common Header> <COPS PEPID> <ClientSI Info> 

<ClientSI Info> = <COPS Client SI Header> <iyiiyi Version Info> 

<Gate Control Command> = <COPS Common Header> <Client Handle> <Context> 

<Decision Flags> <ClientSI Data> 
<ClientSI Data> = <Gate-Set> | <Gate-Info> | <Gate-Delete> | 

<PDP-Config> | <Synch-Request> | <Msg-Receipt> 
<Gate Control Response> = <COPS Common Header> <Client Handle> <Report Type> 

<ClientSI Object> 
<ClientSI Object> = <Gate-Set-Ack> | <Gate-Set-Err> | <Gate-Info-Ack> | <Gate-Info-Err> | 
<Gate-Delete-Ack> | <Gate-Delete-Err> | < Gate-Report-State> | 
<Gate-Cmd-Err> | <PDP-Conf ig-Ack> | <PDP-Conf ig-Err> | 
<Synch-Report> | <Synch-Complete> 
<Gate-Set> = <Decision Header> <TransactionID> <AMID> <SubscriberID> [<GateID>] 
<GateSpec> <Traffic Profile> <classifier> [<classif ier . . . >] 
[<Event Generation Info>] [<Volume-Based Usage Limit>] 
[<Time-Based Usage Limit>] [<Opaque Data>] 
[<UserID>] 
<Gate-Set-Ack> = <ClientSI Header> <TransactionID> <AMID> <SubscriberID> <GateID> 

[<Opaque Data>] [<Msg-Receipt-Key>] [<SharedResourceID>] 
<Gate-Set-Err> = <ClientSI Header> <TransactionID> <AMID> <SubscriberID> 

<IPCablecom Error> [<Opaque Data>] [<Msg-Receipt-Key>] 
<Gate-Info> = <Decision Header> <TransactionID> <AMID> <SubscriberID> <GateID> 

[<PSID>] 
<Gate-Info-Ack> = <ClientSI Header> <TransactionID> <AMID> <SubscriberID> <GateID> 

[<Event Generation Info>] <Gate-Spec> <classifier> <classif ier . . . >] 
<Traffic Profile> <Gate Time Info> <Gate Usage Info> 
[<Volume-Based Usage Limit>] 
[<PSID>] [<Msg-Receipt-Key>] [<UserID>] 

[<Time-Based Usage Limit>] [<Opaque Data>] <GateState> 
[<SharedResourceID>] 
<Gate-Info-Err> = <ClientSI Header> <TransactionID> <AMID> <GateID> <IPCablecom Err> 

[<Opaque Data>] [<PSID>] [<Msg-Receipt-Key>] 
<Gate-Delete> = <Decision Header> <TransactionID> <AMID> <SubscriberID> <GateID> 

[<PSID>] 
<Gate-Delete-Ack> = <ClientSI Header> <TransactionID> <AMID> <GateID> [<Opaque Data>] 

[<PSID>] [<Msg-Receipt-Key>] 
<Gate-Delete-Err> = <ClientSI Header> <TransactionID> <AMID> <GateID> 
<IPCablecom Error> [<Opaque Data>] 
[<PSID>] [<Msg-Receipt-Key>] 
<Gate-Report-State> = <ClientSI Header> <TransactionID> <AMID> 
<SubscriberID> <GateID> <GateState> 
<Gate Time Info> <Gate Usage Info> [<Opaque Data>] 
[<Msg- Receipt- Key >] 
[<SharedRe source ID >] 
<Gate-Cmd-Err> = <ClientSI Header> <TransactionID> <AMID> <IPCablecom Error> 
<PDP-Config> = <Decision Header> <TransactionID> <PSID> 

<PDP-Conf ig-Ack> = <ClientSI Header> <TransactionID> [<Msg-Receipt-Key>] 

<PDP-Conf ig-Err> = <ClientSI Header> <TransactionID> <IPCablecom Error> [<Msg-Receipt-Key>] 
<Synch-Request> = <Decision Header> <TransactionID> [<AMID>] [<PSID>] [<SubscriberID>] 

<Synch Options> 
<Synch-Report> = <ClientSI Header> <TransactionID> <AMID> [<PSID>] 
<SubscriberID> <GateID> <GateState> 
<Gate Time Info> <Gate Usage Info> [<Opaque Data>] 

[<GateSpec>] [<Traffic Profile>] [<Classif ier...>] [<Event Generation Info>] 
[<Volume-Based Usage Limit>] [<Time-Based Usage Limit>] 
[<Msg-Receipt-Key>] [<UserID>] [<SharedResourceID>] 
<Synch-Complete> = <ClientSI Header> <TransactionID> [<AMID>] [<PSID>] 

[<IPCablecom Error>] [<Msg-Receipt-Key>] 
<Msg-Receipt> = <Decision Header> <TransactionID> <Msg-Receipt-Key> 
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There are six basic Gate Control command messages: Gate-Set, Gate-Info, Gate-Delete, PDP-Config, Synch-Request, 
and Msg-Receipt. These messages are embedded in the Client-Specific Decision Data in a COPS Decision message. For 
Gate Control command messages, the Context object (C-Num = 2, C-Type = 1) in the COPS Decision message shall 
have the R-Type (Request Type Flag) value set to 0x08 (Configuration Request) and the M-Type set to zero. The 
Command-Code field in the mandatory Decision-Flags object (C-Num = 6, C-Type = 1) shall be set to 1 (Install 
Configuration). Other values shall cause the CMTS to generate a Report-State message indicating failure. The flags 
subfield may be set to any value and shall be ignored by the PEP. The Gate Command Type field in the TransactionID 
object distinguishes the type of command being issued. 

There are twelve Gate Control response messages: Gate-Set- Ack, Gate-Set-Err, Gate-Info- Ack, Gate-Info-Err, Gate- 
Delete- Ack, Gate-Delete-Err, Gate-Cmd-Err, PDP-Config-Ack, PDP-Config-Err, Synch-Report, Synch-Complete, and 
Gate-Report-State. The first eleven Gate Control response messages are solicited responses to Gate Control command 
messages. The twelfth, Gate-Report-State, is an unsolicited response to the PS from the CMTS to inform of a state 
change. 

These messages are embedded in the Client-Specific Information Object in COPS Report-State messages. The Report- 
Type object (C-Num = 12, C-Type = 1) included in the COPS Report-State message for Gate Control responses shall 
have the Report-Type field set to 1 (Success) or 2 (Failure) depending on the outcome of the Gate Control command. 
Report-State messages in response to a Gate Control command shall have the solicited message flag bit set in the COPS 
header. The Gate Command Type field in the TransactionID object distinguishes the type of response being issued. 

The CMTS generates the Gate-Report-State message when there is a state transition on the Gate that is not due to a 
Decision message, or when some policy limit has been reached. For the Gate-Report-State message, the Report-Type 
field shall be set to 3 (Accounting), and the solicited flag field in the common header shall be cleared. 

If an object that is received in a Gate Control message contains an S-Num or S-Type that is invalid or unknown, that 
object shall be ignored. An object is considered unknown if it has an S-Num/S-Type that is not defined in the present 
document. An object is considered invalid if it has a defined S-Num/S-Type and is present in a message for which that 
object type is not allowed. The presence of such an object within a Gate Control message shall not be treated as an error 
provided that after such parameter is dropped, all required objects are present in the message. 

6.5 Gate Control Protocol Operation 
6.5.1 Initialization Sequence 

When a PEP (Policy Server or CMTS) boots, it shall listen for incoming COPS connections on the lANA-assigned TCP 
port number 3918. Any Application Manager or Policy Server (PDP) with a need to contact a PEP shall initiate a TCP 
connection to the PEP on that port. It is expected that multiple Application Managers will establish COPS connections 
with multiple Policy Servers, and multiple Policy Servers will establish COPS connections with multiple CMTSs. When 
the TCP connection between the PEP and the PDP is established, the PEP shall send information about itself to the PDP 
in the form of a Client-Open message. This message shall include the Multimedia Version Info object, which will 
inform the PDP of the currently supported Multimedia protocol version used on the PEP. 

Upon successful receipt of the Client-Open message, the PDP shall send a Client- Accept message if the protocol 
version specified in the Version Info object is supported. This message shall include the Keep- Alive-Timer object, 
which tells the PEP the maximum interval between Keep- Alive messages. 

If the protocol version supplied by the PEP is not supported, the PDP shall send a Client-Close messages with a COPS 
Error Object specifying error code 4 (Unable to process). After sending the Client-Close, the PDP shall retain the TCP 
connection and security association with the PEP so that the PEP can reattempt the COPS initialization without 
reestablishing the TCP connection and security association. After receiving a Client-Close message from the PDP, 
which includes a COPS Error Object specifying error code 4, the PEP may reattempt initialization of the COPS 
connecting by sending another Client-Open message with another version number in the Version Info Object. This 
process may continue until the PEP has either received a Client- Accept message from the PDP, or has exhausted all 
available protocol versions. Once the PEP has tried all the protocol versions it supports, the PEP shall send a Client- 
Open message with a Major Version Number of and a Minor Version Number of to indicate that it has 
unsuccessfully completed the version negotiation process. The PDP shall then send a Client-Close message to the PEP 
to acknowledge that protocol negotiation has failed. On receipt of the Client-Close, the PEP shall close the TCP 
connection. At this point, the PDP may periodically attempt to re-establish the connection. 

Devices compliant with the present document shall use a version of 4.0, i.e. a Version Info Object with a Major Version 
Number of 4 and a Minor Version Number of 0. 
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Upon successful receipt of the Client- Accept message, the PEP shall send a Request message, including the Client- 
Handle and Context objects. The Context object (C-Num = 2, C-Type = 1) shall have the R-Type (Request Type Flag) 
value set to 0x08 (Configuration Request) and M-Type set to zero. The Client-Handle object contains a value that shall 
be chosen by the PEP. The only requirement imposed on this value is that a PEP shall not use the same value for two 
different Requests on a single TCP connection. This completes the initialization sequence, which is visually depicted 
below. 



PDP 



PEP 



TCP Connection to multimedia port 



GOPSOPN 



COPS GAT 
COPS REQ 



COPS Connection is initialized 



Figure 5: COPS Connection Establishment 

Periodically, the PEP shall send a COPS Keep-Alive (KA) message to the PDP. Upon receipt of the COPS KA 
message, the PDP shall echo a COPS KA message back to the PDP. This transaction is shown below and is fully 
documented in [9]. The PEP shall send a Keep- Alive message at least as often as specified in the Keep- Alive-Timer 
object returned in the Client-Accept message. The Keep- Alive message shall be sent with Client-Type set to zero and 
the solicited flag cleared. 



PDP 



PEP 



COPS KA 



COPS KA 



Figure 6: COPS Keep-Alive Exchange 

6.5.2 Operation Sequence 

The protocol between the PDP and PEP is used for purposes of resource control and resource allocation policy. The 
Application Manager requests policy decisions from the Policy Server, and the Policy Server authorizes the requests 
and installs them on the CMTS for enforcement through the use of Gates. 

Messages that may be initiated by the Application Manager and Policy Server include Gate-Set, Gate-Info and Gate- 
Delete. The CMTS may initiate Gate-Report-State messages. The procedures for these messages are described in the 
following clauses. All messages from the PDP to the PEP shall be sent using Client-Specific objects within the Decision 
object of a COPS Decision message. Solicited responses from the PEP shall be sent as a Report-State message with 
Client-Specific objects in the ClientSI object, and the solicited flag shall be set. Gate-Report-State messages from the 
CMTS shall be sent as unsolicited Report-State messages via Client-Specific objects in the ClientSI object. 

The Decision messages and Report-State messages shall contain the same Client-Handle as provided in the initial 
Request sent by the CMTS when the COPS connection was initiated. 

Gate-Set initializes and modifies all the policy and traffic parameters for the Gate and establishes billing information. 
Gate-Set may also be used to control and update the state of a Gate on the CMTS. 
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Gate-Info is a mechanism by which the Policy Server may query all the current state and parameter settings of an 
existing Gate. 

Gate-Delete allows a Policy Server to delete a specific Gate and any associated Service Flow. 

Gate-Report-State allows the CMTS to inform the Policy Server that the Gate has transitioned into a new state. Gate- 
Report-State messages shall be generated when the state transition happens asynchronously (i.e. not as a response to a 
Gate-Set message). Gate-Report-State messages shall not be generated when the state transition happens synchronously. 

Each Gate Control message that is sent by a PDP shall include the TransactionID object. If this object is missing, the 
Gate Control message shall be discarded and no response message be generated. If the TransactionID object contains an 
unknown or invalid (e.g. Gate-Delete-Err or Gate-Report-State) Gate-Command-Type value, an Gate-Cmd-Err error 
message shall be generated by the PEP. Gate-Cmd-Err takes precedence over all other errors. 

If the Gate Control message contains invalid or unknown objects, these objects shall be ignored. If the Gate Control 
message contains missing mandatory objects, or other errors, then the error shall be reported in the corresponding error 
message. No precedence of order of error checking is mandated. 

In addition to the TransactionID, each Gate Control error message defines a set of mandatory elements. For each 
mandatory object that is missing in the original Gate Control message, a corresponding object with a null value shall be 
generated for the response. The null value for AMID, SubscriberlD, and GatelD is defined to be zero. 

The PEP shall periodically send a Keep- Alive (KA) message to the PDP to facilitate the detection of TCP connection 
failures. The PDP shall keep track of when KAs are received. If the PDP has not received a KA from the PEP in the 
time interval specified in [9] and the PDP has not received an error indication from the TCP connection, then the PDP 
shall tear down the TCP connection and attempt to re-establish the TCP connection. 

The following rules are used to route Gate Control messages through the IPCablecom Multimedia framework. In 
particular, provisions are provided for passing Gate Control messages forward (i.e. AM-to-PS-to-CMTS) and backward 
(i.e. CMTS-to-PS-to-AM) through a complex layered network in which multiple instances of each element are 
interacting with elements in the adjoining layer(s). 

Upon receipt of a Gate Control message from an AM, a PS will apply any provisioned policy rules and determine 
whether to admit or reject the request. If the request is successfully admitted, the PS shall route the message to the 
appropriate CMTS based on the SubscriberlD included in the message. This SubscriberlD-to-CMTS mapping may be 
performed dynamically based on a query to the OSS infrastructure or may reflect pre-provisioned routing information 
related to the range(s) of IP subnets that are associated with each CMTS. 

If a Gate Control request is rejected by the PS, an error response shall be returned to the issuing AM over the 
connection on which the original request was received. If a failure is detected on this connection between the time that a 
request is received and the response is delivered, the PS shall discard the response. 

Upon receiving a Gate Control message from a PS, a CMTS will execute the requested operation. If this operation is a 
successful Gate-Set operation, the CMTS shall record the AMID and SubscriberlD included in the message and 
maintain an association with the referenced Gate. This information must be used to ensure that only the AM which 
originally created the Gate is allowed to query or modify it. Any Gate Control messages that reference a Gate but which 
contain a AMID other than the one associated with the Gate shall be rejected by the CMTS with error "Unauthorized 
AMID". If the PS that sent a Gate Control message had previously declared a PSID in a PDP-Config message then the 
CMTS shall also maintain an association between that PSID and the referenced Gate. Gate-Report-State messages for a 
gate shall be delivered to the PS element, identified through its PSID, that was last used to successfully perform a Gate- 
Set operation on that gate. 

When a PS receives a Gate-Report-State message from a CMTS, the PS shall forward this message to the AM 
associated with the AMID included in the message. In order to maintain a level of abstraction between non-adjacent 
layers and to hide information related to network topology from the AM layer, the PS shall not include information 
directly identifying a particular CMTS to the AM layer. 

6.5.3 Procedures for Validating Resource Envelopes 

The set of service flow characteristics that are important for the purposes of providing enhanced Quality of Service is 
known as the envelope. A IPCablecom Multimedia Gate contains up to three envelopes - one that indicates the 
Authorized resources, one that indicates the Reserved resources, and one that indicates the Committed resources for the 
service flow corresponding to the Gate. 
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The AM shall ensure that the Committed envelope fits within the Reserved Envelope which fits within the Authorized 
envelope. For a Multicast Gate, the AM shall set the Authorized, Reserved, and Committed envelopes identically when 
provided. 

When a CMTS receives a Gate-Set message, it validates the relation between the Committed, Reserved, and Authorized 
envelopes of the Gate. The CMTS shall confirm that the Committed envelope fits within the Reserved Envelope which 
fits within the Authorized envelope. For a Multicast Gate, the CMTS shall also confirm that the Authorized envelope. 
Reserved envelope, and, where provided. Committed envelope are all identical. If the envelope relation is invalid, the 
CMTS shall reply with a Gate-Set-Err message with a IPCablecom Error-Code of "Incompatible Envelope". 

For a Multicast Gate, the AM should provide the Authorized envelope. Reserved envelope, and Committed envelope in 
one Gate-Set message. If the Multicast Gate does not include a Committed envelope and the CMTS does not support a 
multiphase committal of a Multicast gate, then the CMTS shall reply with a Gate-Set-Err message with a IPCablecom 
Error-Code of "Uncommitted Multicast Not Supported". 

The CMTS shall also perform admission control whenever a change (including an addition) of the reserved envelope is 
requested. Admission control is the process of assigning resources for the fiow corresponding to the gate. If the 
resources cannot be assigned, the CMTS shall reply with a Gate-Set-Err message with a IPCablecom Error-Code of 
"Insufficient Resources". 



6.5.3.1 



Flow Spec 



In table 3, the second column indicates the operation that should be used to compare a parameter of A's envelope to a 
corresponding parameter in B's envelope. In other words, envelope A fits within envelope B if each of A's parameters 
meets the criteria specified in the table. 

Table 3: Envelope Comparison Rules 



Parameter 


A{OP}B 


Token Bucket Rate [r] 


< 


Token Bucket Size [b] 


< 


Peak Data Rate [p] 


< 


Minimum Policed Unit [m] 


> 


Maximum Packet Size [M] 


< 


Rate [R] 


< 


Slack Term [S] 


> 



6.5.3.2 



DOCSIS Service Class Name 



For traffic profiles in the form of a Service Class Name, the Service Class Name string shall exactly match the 
preexisting Service Class Name on the CMTS. No envelope comparison is necessary as all three envelopes must share 
the same envelope parameters. 



6.5.3.3 



DOCSIS Service Flow Parameters 



6.5.3.3.1 



Upstream Encodings 



In table 4, the second column indicates the operation that should be used to compare a parameter of A's envelope to a 
corresponding parameter in B's envelope. In other words, envelope A fits within envelope B if each of A's parameters 
meets the criteria specified in the table. 
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Table 4: Upstream Envelope Comparison 



Parameter 


A {OP} B 


Traffic Priority (BE & NRTPS) 


< 


Request Transmission Policy (all) 


== 


Maximum Sustained Traffic Rate (BE, NRTPS, RTPS) 


< 


IVIaximum Traffic Burst (BE, NRTPS, RTPS) 


< 


Minimum Reserved Traffic Rate (BE, NRTPS, RTPS) 


< 


Assumed Minimum Reserved Traffic Rate Packet Size (BE, 
NRTPS, RTPS) 


> 


Maximum Concatenated Burst (BE, NRTPS, RPTS) 


< 


Nominal Polling Interval (NRTPS, RTPS, UGS/AD) 


See interval description below 


Tolerated Poll Jitter (RTPS, UGS/AD) 


> 


Unsolicited Grant Size (UGS & UGS/AD) 


< 


Grants per Interval (UGS & UGS/AD) 


< 


Nominal Grant Interval (UGS & UGS/AD) 


See interval description below 


Tolerated Grant Jitter (UGS & UGS/AD) 


> 



Intervals - A is a subset of B if the parameter in A is an integer multiple of the same parameter in B. 

The Required, Forbidden, and Attribute Aggregation masks are ignored by the CMTS when comparing envelopes. 
Application Managers should set each of the Required, Forbidden, and Attribute Aggregation masks in a consistent way 
across the Authorized, Reserved, and Committed envelopes. 



6.5.3.3.2 



Downstream Encodings 



In table 5, the second column indicates the operation that should be used to compare a parameter of A's envelope to a 
corresponding parameter in B's envelope. In other words, envelope A fits within envelope B if each of A's parameters 
meets the criteria specified in the table. 

Table 5: Downstream Envelope Comparison 



Parameter 


A {OP} B 


Traffic Priority 


< 


Maximum Sustained Traffic Rate 


< 


Maximum Traffic Burst 


< 


Minimum Reserved Traffic Rate 


< 


Assumed Minimum Reserved Traffic Rate Packet Size 


> 


Maximum Downstream Latency 


> 


Downstream Peak Traffic Rate 


< 



The Required, Forbidden, and Attribute Aggregation masks are ignored by the CMTS when comparing envelopes. 
Application Managers should set each of the Required, Forbidden, and Attribute Aggregation masks in a consistent way 
across the Authorized, Reserved, and Committed envelopes. 



6.5.3.4 



Upstream Drop 



Gate-Set commands with a traffic profile of type Upstream Drop do not contain envelope attributes. As a result, the 
CMTS need not perform resource envelope validations. 

6.5.4 Procedures for Authorizing Resources tinrougin a Gate 

The Gate-Set message may be sent by the PDP to the PEP to initialize or modify the operational parameters of a Gates. 
Figure 7 provides an example of Gate-Set signalling. 

NOTE: As an example, the "Start Session" message can be used to indicate to the Client that the resources have 
been authorized. 
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Client 



PEP 



PDP 



Start Session 



GATE-SET 



GATE-SET-ACK 



Figure 7: Sample Signalling of Gate-Set 

If a GatelD object is present in the Gate-Set message, then the request is to modify an existing Gate. If the GatelD 
object is missing from the Gate-Set message, then it is a request to allocate a new Gate. The Gate-Set message shall 
contain exactly one GateSpec object, describing one upstream or downstream Gate. 

The Gate-Set message also contains the SubscriberlD. The CMTS shall use this IP address (i.e. the SubscriberlD) to 
determine the servicing CM and shall use the MAC address of the CM for subsequent MAC -layer messaging. The 
CMTS shall consider all SubscriberlDs which are routable via a CM as valid SubscriberlDs. 

The PEP shall respond to a Gate-Set message with either a Gate-Set-Ack, indicating success, or a Gate-Set-Err, 
indicating failure. The TransactionID in the response shall match the TransactionID in the request. Errors in allocating 
or authorizing Gates shall be reported by a Gate-Set-Err response. Refer to clause 6.4.2.14. 

In Scenario 1, the Policy Server may specify the Authorized, Reserved and Committed Envelopes via a Traffic Profile 
sent in the Gate-Set message. It may simultaneously instruct the CMTS to authorize, reserve and commit resources. 

Upon the receipt of a Gate-Set, the CMTS must first meet the requirements specified in clause 6.5.3 and then perform 
the requested actions. Upon successful completion of the actions requested in the Gate-Set (e.g. creation of a DOCSIS 
Service Flow) the CMTS shall respond with a Gate-Set-Ack. The CMTS shall not respond with a Gate-Set-Ack until it 
has completed sufficient steps to ensure that any subsequent requests to Admit or Commit the Gate will not fail due to a 
lack of resources. 

A CMTS may perform complex authorization based not only on the requested QoS and the Gate's authorized FlowSpec, 
but also based on the SessionClassID specified in the GateSpec. The CMTS may have provisioned policies that define 
the amount of resources allocated exclusively to the particular Session Class, as well as "borrow" and "preemption" 
rules that apply to the use of the resources. The specifics of these types of policies and rules on the CMTS are out of 
scope for the present document. 

Upon receipt of a Gate-Set-Ack or Gate-Set-Err from a CMTS, the Policy Server shall forward the message to the 
Application Manager corresponding to the AMID in the Gate-Set-Ack. The Policy Server shall not transmit a Gate-Set- 
Ack to an Application Manager prior to receiving a Gate-Set-Ack from the CMTS. If the Application Manager requests 
a service that does not pass the Policy Server's policy checks, however, the Policy Server shall not send the Gate-Set to 
the CMTS and shall send a Gate-Set-Err to the Application Manager with the appropriate errors set. 



6.5.4.1 



Procedures for Authorizing Multicast Gates 



In addition to the requirements specified in clause 6.5.4 above, the following requirements are added for Multicast Gate 
requests. 

Upon receipt of a Gate-Set message without a GatelD and with a classifier specifying a destination IP address of type 
Multicast, the CMTS shall determine if this Multicast Gate request can be serviced by an existing SharedResourcelD. If 
the Multicast Gate request is to be serviced by an existing resource with an assigned SharedResourcelD, then the CMTS 
shall include the identified SharedResourcelD in the Gate-Set-Ack returned to the PS. If the Multicast Gate request will 
not be serviced by an existing resource with an assigned SharedResourcelD, then the CMTS shall determine whether it 
has resources available to service the Multicast Gate request. If the CMTS determines it can satisfy the request, it shall 
create a new SharedResourcelD and return it in the resulting Gate-Set-Ack. 
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DOCSIS 3.0 introduces a CMTS IP Multicast Join Authorization feature that allows operators to control which IP 
multicast sessions may be joined by multicast clients reached through a CM, by configuring rules on the CMTS. The 
CMTS shall always authorize the IP multicast sessions signalled via IPCablecom Multimedia Gate-Set messages to be 
joined by clients reached through a CM in spite of any authorization rules which may be configured locally on the 
CMTS. 

The CMTS shall use the QoS parameters signalled via Gate-Set message for the instantiation of the Group Service Flow 
associated with the multicast replication referenced in the Classifier specified in the Gate-Set message. The CMTS shall 
ignore the CmtsGrpQosCfg entry associated with the classifier contained within the Multicast Gate request. If the 
Multicast Gate request signals a QoS envelope that is different than the QoS envelope associated with the 
SharedResourcelD the CMTS has chosen to service the Multicast Gate request, the CMTS may reject the request with a 
Gate-Set-Err message with a IPCablecom Error-Code of 34 (Multicast QoS Error). 

If the CMTS cannot satisfy the Multicast Gate request (for any of the reasons herein, or due to local policy), it shall 
return a Gate-Set-Err with an appropriate error code. 

The CMTS shall support Multicast Gates in the downstream direction. The CMTS may reject Multicast Gate requests 
which would result in an upstream Multicast Gate with error code 32 (Upstream Multicast Not Supported). 

A Multicast Gate request will also contain a GateSpec object which defines the timers to be used for the gate state 
transitions as well as DSCP values and SessionClassID. It is possible that the CMTS may receive conflicting GateSpec 
parameters by the AM for Multicast Gate requests (e.g. multiple Multicast Gate requests for the same Multicast 
destination but with different timer values). In such a case the CMTS shall either individually implement the GateSpec 
timer and DSCP values for each Multicast Gate request or reject Multicast Gate requests which do not match the DSCP 
and timer values associated with the underlying shared resource identified by the CMTS to service the Multicast Gate 
request. If the CMTS chooses to reject the Multicast Gate request due to incompatible GateSpec parameters, it shall use 
error code 33 (Multicast GateSpec incompatibility). 



6.5.5 Procedures for Querying a Gate 



When a Policy Server or Application Manager wishes to query the current parameter settings of a Gate, it sends to the 
CMTS a Gate-Info message. The CMTS shall respond to a Gate-Info message with either a Gate-Info-Ack, indicating 
success, or a Gate-Info-Err, indicating failure. A Gate-Info-Ack shall contain all the current information on the Gate 
associated with the GatelD in the Gate-Info message. If the Gate being queried has an existing Volume-Based and/or 
Time-Based Usage Limit, then the CMTS shall include these objects in the Gate-Info-Ack. If the Gate being queried is 
a Multicast Gate, then the CMTS shall include the current SharedResourcelD in the Gate-Info-Ack. A PS or AM can 
utilize this information to recover Gate state information from the CMTS for policing, error recovery or other purpose. 
The TransactionID in the response shall match the Transaction© in the request. 

Errors in querying gates shall be reported by a Gate-Info-Err response. 



6.5.6 Procedures for Modifying a Gate 



To modify the Traffic Profile associated with an existing Gate, an Application Manager may send a Gate-Set message 
with the GatelD of the Gate to be modified and the new Traffic Profile. If the Gate-Set fails the Policy Server's checks, 
the Policy Server shall send a Gate-Set-Err to the Application Manager and shall not send a Gate-Set to the CMTS. 
However, if the Gate-Set passes the Policy Server's policy checks, the Policy Server shall send the Gate-Set to the 
CMTS. The TransactionID in the Policy Server Gate-Set shall match the TransactionID in the Application Manager 
Gate-Set. 

Upon the receipt of a Gate-Set, the CMTS must first meet the requirements specified in clause 6.5.3 and then perform 
the requested actions. As with the creation of a new Gate, upon successful completion of the actions requested in the 
Gate-Set (e.g. modification of a DOCSIS service flow) the CMTS shall respond with a Gate-Set-Ack. The CMTS shall 
not respond with a Gate-Set-Ack until it has completed a sufficient number of steps to ensure that any subsequent 
requests to Admit or Commit the Gate will not fail due to lack of resources. 

Upon receipt of a Gate-Set-Ack or Gate-Set-Err from the CMTS, the Policy Server shall forward the response to the 
Application Manager. 
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To modify the Usage Limits associated with an existing Gate, an Application Manager may send a Gate-Set message 
with the GatelD of the Gate to be modified. If the Traffic Profile in the Gate-Set is different from the Traffic Profile 
currently associated with the Gate, then the previous rules apply. In either case, if the Time-Based Usage Limit or 
Volume-Based Usage Limit of the flow is present, then the existing limits associated with this/these parameter(s) shall 
be replaced with the new parameter(s). However, the absence of these parameters from a Gate-Set message indicates 
that even if the Traffic Profile for the Gate is being modified, the existing Time-Based or Volume-Based Usage Limit(s) 
of the Gate still apply. If these parameters are not present in a Gate-Set message, the existing limits shall be maintained 
and their associated counters/timers shall continue from their current value without resetting. 

6.5.6.1 Procedures for Modification of Multicast Gates 

If a Gate modification request for a Multicast Gate changes the resource requested by the Gate to be another shared or 
unshared resource, the CMTS shall re-apply admission control logic for the newly requested resource, as it would 
during an initial Gate creation request, see clause 6.5.4. L The CMTS may refuse to allow such transitions. When 
rejecting such gate modification requests, the CMTS shall return a Gate-Set-Err with Error Code 31 (Multicast Gate 
Modification Not Supported). Note that a Classifier change (e.g. a Multicast Group Address Change) to the Gate may 
result in a change in shared resource usage for this Gate. The Gate-Set- Ack message shall include the 
SharedResourcelD for the Gate using the new Multicast Classifier. 

If a Gate modification request for a Multicast Gate changes the source and/or destination IP address for a committed 
gate, and the CMTS supports such a change, the CMTS should treat the Gate-Set message as a "LeaveMulticastSession" 
for the old multicast session specified in the Gate and a "JoinMulticastSession" for the new multicast session specified 
in the Gate. For more information regarding handling of "JoinMulticastSession" and "LeaveMulticastSession" please 
refer to [ 1 ] . 

6.5.7 Procedures for Supporting Usage Limits 

The Application Manager, Policy Server and CMTS all have a role in enforcing Usage Limits. There are subtle 
differences between Time-Based and Volume-Based Limits so each of these is described separately. 

The Volume-Based and Time-Based Usage Limits are relative to the Gate-Usage-Info and Gate-Time-Info values 
respectively. In order to support this, the Volume-Based and Time-Based Usage Limits are used as cumulative values. 
For example, if an Application Manager wants a Gate-Report-State generated when a Gate reaches 100 kilobytes of 
traffic, then it would send a Volume-Based Usage Limit of 100 kilobytes (if sent at the creation of the Gate, where the 
current value of Gate-Usage-Info is 0). If it then wanted a Gate-Report-State message generated when a Gate reaches 
350 kilobytes, it would send a Volume-Based Usage Limit of 350 kilobytes, not 250 kilobytes. Along these lines, if an 
Application Manager wants to set a Volume-Based Usage Limit of 100 kilobytes after a Gate has already been created 
and has a non-zero value for Gate-Usage-Info, it should send a Gate-Info message to obtain the current value of Gate- 
Usage-Info add 100 kilobytes to that value, and use this new value in the Volume-Based Usage Limit in a subsequent 
Gate-Set. 

Given the CMTS is the only device that tracks both Gate-Usage-Info and Gate-Time-Info, it is required to generate a 
Gate-Report-State notifying the AM when a Volume-Based or Time-Based Usage Limit is set less than or equal to the 
current Gate-Usage-Info or Gate-Time-Info value respectively. If the Volume-Based Usage Limit is set less than the 
current Gate-Usage-Info value, the CMTS shall send a Gate-Report-State message with a Gate-State reason code of 7 
(Gate state unchanged, but volume limit reached). If the Time-Based Usage Limit is set less than the current Gate- 
Time-Info value, the CMTS shall send a Gate-Report-State message with a Gate-State reason code of 10 (Gate state 
unchanged, but time limit reached). This is the only case where the CMTS would send reason code 10 since the CMTS 
is not responsible for tracking Time Based Usage Limits, see clause 6.5.7.2. Using zero (0) for a Usage Limit is an 
exception to this, as it is used to disable the Usage Limit. In addition, the Gate-Usage-Info object within a Gate-Report- 
State message is not applicable to gates created with a traffic profile of Upstream Drop. The CMTS shall return a value 
of zero (0) bytes. 

Depending on the CMTS implementation, volume usage tracking and volume-based usage limits for individual 
Multicast Gates may be unsupported. If the CMTS does not support tracking volume usage per Multicast Gate, it shall 
reject any Multicast Gate-Set message including a Volume Based Usage Limit. In such a case, the CMTS shall specify 
error code 29 (Multicast Volume Limit Unsupported), in the resulting Gate-Set-Error message. 
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6.5.7.1 Procedures For Supporting Volume-Based Usage Limits 

Since the CMTS is the only trusted IPCablecom Multimedia device in the packet path, it is the only device capable of 
accurately tracking the usage of individual Gates. Thus, the CMTS shall track the usage of all Gates regardless of 
whether or not they have an associated Volume-Based Usage Limit. The CMTS may track the usage of individual 
Multicast Gates. The CMTS shall report the amount of data transferred via a Unicast Gate in all Gate-Info- Ack and all 
Gate-Report-State messages. If the CMTS does not support tracking volume usage on individual Multicast Gates, it 
shall use a zero value for the Gate Usage Info object in all Gate-Info-Ack and Gate-Report-State messages, and also not 
include a Volume Based Usage Limit object. 

If the Gate has an associated Volume-Based Usage Limit when the amount of data that has traversed the Gate equals the 
Volume-Based Usage Limit, the CMTS shall send a Gate-Report-State message with the Solicited bit set to 0. The 
Gate-Report-State message shall include a Gate State object with the Reason set to 7 (Gate state unchanged, but volume 
limit reached). Upon receipt of a Gate-Report-State message, the behavior of a PDP depends upon its role; a Policy 
Server shall either forward the Gate-Report-State message to the Application Manager, or handle the report itself The 
Policy Server should only handle the report if it caused the report to be generated by modifying the original gate set. In 
other words, the Policy Server's actions should be transparent to the Application Manager. The Application Manager 
shall handle received reports. A PDF handles a Gate-Report-State message with the Reason set to 7 by performing one 
of the following actions: 

• Send a Gate-Set message with a new Volume-Based Usage Limit object. 

• Send a Gate-Set message with a Volume-Based Usage Limit set to to explicitly disable the feature, or do 
nothing to implicitly disable the feature. 

• Close the Gate by issuing a Gate-Delete command. 

6.5.7.2 Procedures For Supporting Time-Based Usage Limits 

While it is a desirable design goal to keep the Volume-Based and Time-Based Usage Limit procedures as similar as 
possible, the number of CMTS interrupts required to support enforcement of Time-Based Usage Limits by the CMTS 
makes this impractical. Thus, the Application Manager shall enforce the Time-Based Usage Limit of the Gate. Upon 
receiving the Gate-Set-Ack for a Gate with a Time-Based Usage Limit, the AM shall start an application timer. When 
the application timer is equal to the Time-Based Usage Limit, the Application Manager shall respond by performing 
one of the following actions: 

• Send a Gate-Set message with a new Time-Based Usage Limit object. 

• Send a Gate-Set message with a Time-Based Usage Limit set to to explicitly disable the feature, or do 
nothing to implicitly disable the feature. 

• Close the Gate by issuing a Gate-Delete command. 

NOTE: In some ways it makes more sense for the Application Manager to enforce Usage Limits, since the Time- 
Based Usage Limit and Volume-Based Usage Limit are a reflection of the service being offered and are 
the responsibility of the Service Control Domain. It is really the Volume-Based Usage Limit procedure 
which is unusual, but the CMTS is the only device that can accurately enforce this limit. 

6.5.7.3 Resource and Error Recovery 

While it is required that the Application Manager perform one of several actions when a Gate's Usage Limit has been 
reached, there is always the possibility that the Application Manager will not respond appropriately. In this case, the 
RKS will still be recording the usage of this Gate so this activity will still be billable, but in some instances it may be 
useful to recover the resources that are being used "illegally" by the Application Manager. A Policy Server may glean 
the fact that the Volume-Based or Time-Based Usage Limit of a Gate has been exceeded based on the messages it is 
proxying between the AM and CMTS. Using the "gleaning" technique implies that the Policy Server is stateful, but a 
Policy Server that is not stateful can still recover resources via a second technique described below. 
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Alternatively, a Policy Server may occasionally query the CMTS with a Gate-Info message. The response will contain 
any associated Volume-Based Usage Limit and Gate Usage Info (or Time-Based Usage Limit and Gate Time Info). The 
Policy Server can then compare these values. Regardless of how a Policy Server gains the knowledge that a Gate is 
over-limit, it may issue a Gate-Delete for over-limit Gates. Upon receipt of the Gate-Delete-Ack from the CMTS, the 
Policy Server shall send a Gate-Report-State with the State set to 1 (Idle/Closed) and Reason set to 1 1 (Close initiated 
by Policy Server or CMTS, volume limit reached) or 12 (Close initiated by Policy Server or CMTS, time limit reached) 
to the Application Manager. If a Gate-Delete-Err is received from the CMTS, the Policy Server shall not send anything 
to the Application Manager because the Gate state is not changed. 

Similarly, while not required to recover resources from over-limit Gates, a CMTS may perform the same comparisons 
itself and may delete over-limit Gates. Additional requirements for this scenario are described in clause 6.5.8. 

Given the fact that the Policy Server and the CMTS may delete over-limit Gates, it is recommended that the Application 
Manager, if it no longer wants to monitor a Volume-Based and/or Time-Based Usage Limit, send a Volume-Based 
and/or Time-Based Usage Limit of 0. This will explicitly disable the Volume-Based and/or Time-Based Usage Limit, 
and will indirectly inform the Policy Server and CMTS that the over-limit Gate has been acted upon. 

6.5.7.4 Tracking Time-Based and Volume-Based Usage Limits 

IPCablecom Multimedia Gates can be committed and uncommitted multiple times (to support, for example, a "pause" 
function on a game or streaming media). Since a subscriber cannot transmit/receive data while the Gate is not a 
committed state, these periods should not be counted against them. For Volume-Based Limits this requirement has no 
effect - there are no packets that might be over counted since no packets can be sent if a Gate is not committed. 
However, for Time-Based Usage Limits the CMTS shall stop its Gate Time Info timer when the Gate is not in either the 
Committed State or the Committed-Recovery State. If the Gate is re-Committed, the Gate Time Info timer shall be 
restarted from its stopped count. 

NOTE: The Application Manager is required to maintain a timer independent of the CMTS timer to enforce the 
Time-Based Usage Limit. Since this timer is separated from the CMTS itself, messaging delays could 
cause discrepancies between these two timers. For applications that require a high-degree of time 
accuracy, the AM may query the CMTS for its Gate Time Info object after it moves a Gate into or out of 
a committed state. 



6.5.8 Procedures for Deleting a Gate 



Normally, when a Multimedia session ends, the Application Manager tells the Policy Server that the session has ended, 
and the Policy Server in turn instructs the CMTS to remove the Gate via a Gate-Delete message. The CMTS shall 
respond to a Gate-Delete message with a Gate-Delete-Ack, indicating success, or a Gate-Delete-Err, indicating failure. 
The TransactionID in the response shall match the Transaction© in the request. 

Errors in deleting Gates shall be reported by a Gate-Delete-Err response. 

At the CMTS, if timer Tl, T2 (only when in the Reserve state), or T4 expires, the Gate shall be deleted. When a CMTS 
deletes a Gate without being solicited by the Policy Server, the CMTS shall send a Gate-Report-State message (with the 
Solicited bit set to 0) to the Policy Server indicating that the Gate was deleted. If the T2 timer expires while in the 
Reserved state, the CMTS shall delete the DOCSIS flow through DOCSIS mechanisms (i.e. a DSD message) and issue 
a Gate-Report-State message (with the Solicited bit set to 0) to the PS informing it of this state transition. Note, if the 
T2 timer expires while in the Committed or Committed-Recovery state then the CMTS must send a DSC as defined in 
DOCSIS to free the reserved resources that are in excess of the active resources, issue a Gate-Report-State message to 
the PS informing it of the reduction in reservation resources, and remain in the same state. Upon receipt of a Gate- 
Report-State message, the Policy Server shall forward it to the Application Manager. 

At the discretion of the Policy Server, for example, as described in clause 6.5.7.3 for resource and error recovery, the 
Pohcy Server may send a Gate-Delete message to the CMTS to delete a gate. 

6.5.8.1 Procedures for Deleting Multicast Gates 

When a Multicast Gate is deleted, the CMTS shall delete all information and state associated with the deleted gate and 
respond with a Gate-Delete-Ack. If the assigned SharedResourcelD is still being used by other Multicast Gates, the 
CMTS shall preserve the SharedResourcelD and the resource it references. If the deleted Multicast Gate is the last Gate 
associated with the assigned SharedResourcelD, the CMTS may delete all information and state associated with the 
SharedResourcelD and the resource it references. 
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When a committed Multicast Gate is deleted, the CMTS should treat the Gate-Delete message as a 
"LeaveMulticastSession" for the multicast session specified in the Gate. For more information regarding handling of a 
"LeaveMulticastSession" refer to [1]. 

6.5.9 Procedure for Committing a Gate 

In Scenario 1, the Policy Server is responsible for committing a Gate through a Traffic Profile containing a Committed 
Envelope. The CMTS commits the Gate and activates the DOCSIS Service Flow using the parameters passed down to it 
by the Policy Server. 

6.5.9.1 Procedure for Committing a Multicast Gate 

When a Multicast Gate is committed, the CMTS should treat the commit operation as a "JoinMulticastSession" for the 
multicast session specified in the Gate. For more information regarding handling of a "JoinMulticastSession" please 
refer to [ 1 ] . 

6.5.10 Termination Sequence 

When the PEP is shutting down its TCP connection to the PDP, it may first send a Delete-Request-State (DRQ) 
message (including the Handle object used in the initial Request message). If the PEP chooses to send the DRQ 
message, the PEP shall use COPS reason code 4 (Tear). The PEP may follow that with a Client-Close message. The 
PDP in response shall automatically delete any state associated with the PEP when the TCP connection is terminated. 
When the PDP is going to shutdown, it should send a COPS Client-Close message to the PEP. In the COPS Client- 
Close message, the PDP should not send the PDP redirect address object PDPRedirAddr. If the PEP receives a COPS 
Client-Close message from the PDP with a PDPRedirAddr object, the PEP shall ignore the PDPRedirAddr while 
processing the COPS Client-Close message. 

The PS and CMTS shall not remove gates as a result of a failed COPS connection. 

6.5.1 1 Procedures for Multiple Grants Per Interval 

Multiple Grants Per Interval provides the ability to map multiple gates (application flows) using identical UGS traffic 
profiles destined for the same CM into a single flow at the DOCSIS level (Service Flow). This is accomplished by 
incrementing the number of grants per interval for each application flow serviced by a single DOCSIS service flow, 
resulting in multiple grants per interval (MGPI). The present document provides support for two approaches to MGPI, 
Flow- Aggregated and One-Flow. Flow- Aggregated MGPI is inherent in the present document and allows the AM to use 
the DOCSIS UGS traffic profile to explicitly set the number of grants per interval and place several application flows 
on a single Gate. This results in an aggregated view for Event Messages, volume and time usage limits and opaque data. 
Due to the inherent nature of this capability, its use is not outlined in this clause, but rather left to the AM to manage 
accordingly. One-Flow MGPI allows the CMTS to choose when to invoke MGPI independently of how the AM 
requests QoS. As far as the AM and PS are concerned, the single application flow per gatelD mapping is preserved, 
while a single underlying DOCSIS resource is used for multiple gates with identical traffic characteristics. This allows 
for each application flow to have its own Event Messages, volume and time usage limits and opaque data while using a 
single DOCSIS Service Flow. 

It is optional for a CMTS to support this feature. If the CMTS chooses to support MGPI functionality, it shall follow the 
procedures outlined in the following clauses. A CMTS should not attempt to invoke MGPI across services types 
(e.g. merge IPCablecom Multimedia and IPCablecom DqoS application flows together) as the interactions are not fully 
understood at this time and it may result in undesired operation. 
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Upon receipt of a Gate-Set without a gatelD, the CMTS shall first satisfy the requirements specified in clause 6.5.3. 
Once the resource envelops have been verified, the CMTS may compare the requested resources against those currently 
reserved or committed for the CM serving the SubscriberlD provided in the Gate-Set. If a FlowSpec traffic profile is 
provided, the CMTS shall translate the FlowSpec parameters to DOCSIS level parameters to make this comparison. If 
the requested QoS parameters (reserved and/or committed) do not match all of the QoS parameters for any of the 
existing service flows and resources are available to support the request, the CMTS shall follow the requirements 
specified in clause 7.5.4 for creating new gates. If all the QoS parameters match and resources are available to support 
the request, the CMTS may modify the existing DOCSIS Service Flow by incrementing the grants per interval by one 
for a traffic profile described by a FlowSpec (or by the grants per interval value provided in a DOCSIS UGS object) and 
by adding the classifier(s) provided in the Gate-Set per the requirements in clause 9.3.4.1. Upon successful completion 
of the actions requested in the Gate-Set (e.g. modification of an existing DOCSIS Service Flow by adding the classifiers 
and incrementing the grants per interval associated with the Gate) the CMTS shall respond with a Gate-Set-Ack. The 
CMTS shall not respond with a Gate-Set-Ack until it has completed sufficient steps to ensure that any subsequent 
requests to Admit or Commit the Gate will not fail due to a lack of resources. 

Once MGPI has been invoked (a second gate has been created using an existing Service Flow), the traffic profile cannot 
be changed by either Gate. If an update to one of the Gates is received which requires changes to the DOCSIS QoS 
parameters, the CMTS shall create a new service flow and remove the application flow from the previously existing 
service flow. If only a single Gate is associated with a service flow, changes to the QoS parameters are allowed without 
creating a new service flow per the requirements in clause 6.5.6. 

When a Gate is removed that is serviced with MGPI, the CMTS shall update the DOCSIS service flow by removing the 
classifiers and decrement the grants per interval associated with the deleted Gate. In the case where the Gate being 
removed is the only flow (admitted or active), the entire DOCSIS service flow shall be deleted as outlined in 
clause 6.5.8. 

The requirements provided in clause 6.5.7.1 shall be followed except as outlined in this clause. When MGPI is invoked, 
the CMTS shall maintain separate octet counters for each Gate associated with the Service Flow. This can be 
accomplished by using the packet counter for each classifier associated with a Gate and then multiplying the packet 
count by the packet size defined by the UGS flow to determine the octet count. It is important to acknowledge that in 
some cases this may not result in exact octet counts, while a UGS flow is deterministic, if an AM has reserved more 
bandwidth (larger packet size) then is actually used by the application, then the octet count will reflect the amount of 
traffic committed to cross the flow vs. the actual. Given this potential, if the CMTS receives a Gate-Set with a volume 
based usage limit it should service this gate with its own DOCSIS service flow to ensure accurate volume tracking is 
provided. 

The One-Flow model also has the following limitations that should be understood, in particular the ability to track 
active flow time and set inactivity time-out limits per application flow is lost. While multiple sub-flows exists, if a 
single flow becomes inactive it will not be flagged by the CMTS as long as the other flows continue to transmit traffic. 
As a result, hung gates could result and persist until all other sub-flows are removed and the activity timer is triggered. 

It is also noted that in addition to the limitations outlined above, the Flow- Aggregated model also looses the following 
capabilities: the ability to fully track each individual flow's reserved-to-committed state transitions, track byte counts 
per flow, track active flow time and set inactivity time-out limits per application flow. In DOCSIS this level of tracking 
and control granularity is only available when a single traffic flow is defined for a service flow. So a decision to utilize 
flow-aggregation is a decision to not access these functions. 

6.5.12 Procedures for Identifying a PDP to a PEP 

When a PDP establishes a new connection with a PEP, it may send a PDP-Config message to declare the AMID(s) (for 
an application manager) or the PSID (for a policy server) that will be used by that PDP. This allows the PEP to 
associate state for this PDP from previous TCP connections with this new connection. For example, this allows a PEP to 
deliver Gate-Report-State messages on a new connection for a gate that may have been created using a connection that 
is no longer available. 

A PDP is not required to send a PDP-Config message. However, if a PDP-Config message is sent then it shall be the 
first message sent on a newly established connection once the connection initialization sequence described in 
clause 6.5.1 is complete. A PDP shall not send more than one PDP-Config message on a single TCP connection If a 
PDP does not send a PDP-Config message for a TCP connection, then it shall not send any state synchronization 
requests on that connection If a PEP receives a message that violates any of these rules it shall send back the appropriate 
error message with an error code of "Unauthorized PSID" (if the PEP is a CMTS) or "Unauthorized AMID" (if the PEP 
is a PS). 
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When a PS receives a PDP-Config message from an AM it should record the association between the TCP connection 
and the AMIDs in the message. The AM may issue requests using an AMID that has not been associated with that TCP 
connection through the PDP-Config message for the connection. When this happens, the PS should assume this is an 
implicit declaration of an association between the new AMID and that TCP connection. An implicit association should 
have the same behavior as an explicit association made with the PDP-Config message. 

When a CMTS receives a PDP-Config message from a PS it should record the association between the TCP connection 
and the PSID in the message. For all subsequent Gate Control operations on that TCP connection the PSID is implicitly 
associated with the gate as part of the operation. 

6.5.13 Procedures for Delivering Gate- Report-State Messages 

To determine how to send a Gate-Report-State message (or any other asynchronous notification message), a PEP should 
follow these steps (in order): 

1. If the PEP has an association between the gate and an active TCP connection (such as the COPS Client 
Handle) then it should send the Gate-Report-State using that connection. 

2. If the PEP is a CMTS, then it should identify all the active PDP connections that have an association with the 
PSID for the gate in the Gate-Report-State. If the PEP is a PS, then it should identify all the active PDP 
connections that have an association with the AMID for the gate in the Gate-Report-State. The PEP can send 
the Gate-Report-State on any of these connections. 

3. If the PEP has an association between the IP Address of the connection originally used to create the gate and 
an active connection, then the PEP may use that connection to send the Gate-Report-State message. 

4. If there is no such connection then the report can be dropped. 

NOTE: If the PEP supports incremental state synchronization the PEP should retain the information in the 
Gate-Report-State. 

6.5.14 Procedures for Gate Control Operations Initiated by a Policy Server 

There may be situations when it is desirable for a Policy Server to initiate a gate control operation (Gate-Info, or 
Gate-Delete) for gates that it may be "managing". For example, during a state synchronization a PS may need to issue a 
Gate-Info request to obtain the complete data for a gate. To accomplish this, the PS issues an operation as if it were sent 
from an AM, but it adds a PSID object to the message. 

For PS-initiated operations the PSID in the request shall be the same as the PSID specified in the PDP-Config message 
for the connection. If the PSID in a request does not match the PSID for the connection then the PEP should return the 
"Unauthorized PSID" error. If a Policy Server is going to issue PS-initiated operations, then it shall send the 
PDP-Config message as described in clause 6.5.12. The TransactionID in a PS-initiated request shall be unique among 
all the outstanding PS-initiated operations submitted to the same CMTS. 

If the PSID object is present in a message, then it indicates that the operation being performed is being initiated by the 
Policy Server instead of the AM. Since the AMID/TransactionID tuple is not unique for PS-initiated operations, the 
CMTS should use the PSID/TransactionID tuple as a unique transaction identifier if one is needed. 

When the response to a PS-initiated operation (either an Ack or Err) is sent from the CMTS, the PSID from the original 
request shall be included in the response. If a PSID was not specified in the original request, then the associated reply 
shall not include a PSID. This allows the Policy Server to distinguish responses to PS-initiated requests from other 
responses that must be forwarded to an AM. 

6.5.15 Procedures for State Synchronization 

This clause provides a general overview of the synchronization process. 
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6.5.1 5.1 Initiating State Synchronization 

Synchronization is always initiated by the PDP. To initiate synchronization, the PDP sends a Synch-Request message to 
the PEP. Although both the PSID and the AMID are optional in this message, one of the two objects shall be present in 
the message. Both objects may be specified. If the PSID is specified, it shall be the same value as the PSID specified in 
the PDP-Config message for the connection. If the PSID does not match, the PEP shall return a Synch-Complete 
message with a IPCablecom Error object with the "Unauthorized PSID" error. 

As is the case with other gate control messages, if the PSID is specified in the request then it represents a PS-initiated 
request and the PSID/TransactionID tuple should be used as a unique transaction identifier. Otherwise the request is an 
AM-initiated request and the AMID/TransactionID tuple should be used as a unique identifier for the transaction. 

Unlike other gate control operations this transaction can consist of multiple replies and is not finished until a Synch- 
Complete message is received by the PDP. All responses to a Synch-Request shall be sent on the same TCP connection 
used to initiate the request. If that connection is terminated before the Synch-Complete message is received then the 
PDP shall consider the synchronization to have terminated abnormally. It may re-issue the synchronization request 
when a new connection is established. 

The PSID, AMID, and SubscriberlD values that are specified in the Synch-Request are used as filtering criteria. The 
PEP shall only include gates in the synchronization that have associations with all the specified values. 

The Synch Options object shall be included in the Synch-Request and is used to specify the type of synchronization to 
be performed, as well as the type of information to be sent back in the synchronization reports. 

6.5.15.2 Full Synchronization 

A full synchronization is one in which the PEP sends information about all the gates that match the filtering criteria 
(PSID, AMID, SubscriberlD) specified in the originating Synch-Request. A PDP requests a full synchronization by 
setting the Synch Type field to in the Synch Options object sent in the Synch-Request. 

A full synchronization only includes gates that are still active (Gate-State is Authorized, Reserved, Committed, or 
Committed-Recovery) - it does not include any gates that have been closed or deleted. 

All PEPs shall support full synchronization. 

A PDP may request a full synchronization at any time. Since a full synchronization may require the PEP to send 
information about many gates this operation can be very resource-intensive and should not be used unnecessarily. 

6.5.15.3 Incremental Synchronization 

An incremental synchronization is one in which the PEP sends information about gates that have had recent state 
changes for which the PDP may not have received notification. It is further restricted to gates that match the filtering 
criteria (PSID, AMID) specified in the Synch-Request. An incremental synchronization request can not include the 
SubscriberlD as filtering criteria. A PDP requests an incremental synchronization by setting the Synch Type field to 1 in 
the Synch Options object sent in the Synch-Request. 

An incremental synchronization should only be performed after a new TCP connection has been established with a PEP. 
The purpose of the incremental synchronization is to provide the PDP with information that may have been lost (or 
missed) while the connection was down. An incremental synchronization is limited to gates that have had Gate-Report- 
State messages whose delivery to the PDP were not confirmed. If the connection between a PDP and PEP has not been 
interrupted recently, then an incremental synchronization request should return no data. 

An incremental synchronization may include gates that are no longer active. For example, if a gate was deleted because 
a timer expired but the associated Gate-Report-State message was undeliverable then that gate shall be included in the 
incremental synchronization even though it no longer exists. 

A PEP may support incremental synchronization. If a PEP receives a request for incremental synchronization and it 
does not support this feature, then it shall return a Synch-Complete message with a IPCablecom Error object with the 
error code set to "Unsupported Synch Type". 
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6.5.15.4 Reporting Gate State Information 

The PEP sends one Synch-Report message to the PDP for each gate that is included in the synchronization. The 
TransactionID in the Synch-Report message shall be the same as the TransactionID in the Synch-Request message that 
initiated the synchronization. The PSID in the Synch-Report shall be the same value that was specified in the Synch- 
Request message. If there was no PSID in the original Synch-Request then there shall not be a PSID in the associated 
Synch-Report messages. All other objects in the Synch-Report shall be set to the values that are associated with the 
gate. 

The Synch-Report message(s) shall be sent on the same TCP connection on which the Synch-Request was received. If 
the connection is terminated before the synchronization is completed, any remaining Synch-Report messages shall be 
dropped. 

There are two variations on a Synch-Report. A "standard report" is limited to the set of objects that are normally 
provided in a Gate-Report-State message for a gate. To request standard reports the PDP sets the Report-Type field to 
in the Synch Options object in the Synch-Request. 

If the PDP needs more information about a gate than is provided in the standard report, it may issue a Gate-Info request 
to retrieve the complete definition of the gate. If the PDP knows in advance that it will need more information than is 
provided by the standard report for every gate included in the synchronization, then it can avoid issuing Gate-Info 
requests for every gate by requesting "complete reports" for each gate. To do this it sets the Report-Type field to 1 in 
the Synch Options object in the Synch-Request. 

A "complete report" contains all the information that is normally provided in a Gate-Info-Ack message. In other words, 
the additional objects in the complete report include: GateSpec, Traffic Profile, Classifier(s), Event Generation Info, 
Volume-Based Usage Limit, and Time-Based Usage Limit. 

Only "standard reports" can be returned for incremental synchronization requests. If a PEP receives a request for an 
incremental synchronization that also requests "complete reports", it shall terminate the request by returning a Synch- 
Complete response with a IPCablecom Error object with the error code for "Invalid Field for Object" and the error 
subcode specifying the Synch-Options object. 

6.5.1 5.5 Completing the Synchronization 

After all the Synch-Report messages for a synchronization request have been sent, the PEP shall send a Synch- 
Complete message to the PDP to signal the end of the synchronization. The AMID and PSID objects shall be specified 
as they were in the Synch-Request that initiated the synchronization. The TransactionID in the Synch-Complete 
message shall be the same as the TransactionID in the Synch-Request message that initiated the synchronization. 

The Synch-Complete message shall be sent on the same TCP connection on which the Synch-Request was received. If 
the connection is terminated before the synchronization is completed, it should be dropped. 

If an error occurs during the synchronization then the PEP shall report the error by sending a Synch-Complete message 
with a IPCablecom Error object. The Error Code should specify the reason for the error. The IPCablecom Error object 
should only be included if there was an error processing the request. 

There are several error codes needed to identify specific situations that may come up during a State Synchronization. 
These include: 



• 



If the PEP has limited resources available for retaining incremental synchronization data and that limit is 
reached (causing it to discard some data), any subsequent incremental synchronization requests should fail 
with the "State Data Incomplete" error code. 

If the PEP is unable to process a synchronization request in a timely fashion because it is busy, it can return a 
Synch-Complete message with the "Insufficient Resources" error code. This does not indicate that the 
synchronization data is not available, only that the request could not be completed at the time it was issued. 
The PDP may re-issue the request at a later time. 



£75/ 



85 ETSI TS 1 02 879 V1 .1 .1 (201 0-06) 

• If a CMTS has rebooted and lost all of its previous state, it must convey this information to any PS that 
requests an incremental synchronization. If it were to simply respond to the PS indicating that it did not have 
any incremental changes then the PS might assume that any previously created gates still existed but this 
assumption is not valid in this situation. Therefore, if a CMTS receives an incremental synchronization request 
from a PS and the CMTS has not created a gate with the PSID for that PS since the CMTS was last rebooted 
(or its state was last initialized) then the CMTS shall return the "No State for PDP" error code. This is an 
indication to the PS that it must delete all state that was previously associated with this CMTS. 

• Note that in the analogous situation where an AM sends an incremental synchronization request to a PS that 
has rebooted (and lost its previous state) the PS also shall return the "No State for PDP" error code. However, 
in this situation the AM should not assume that previously existing gates have been deleted (because they may 
still exist in the CMTS). In this situation this message indicates to the AM that the PS is uncertain whether 
some incremental changes may have been lost and the AM should issue a full synchronization request in order 
to accurately determine the state of any previously existing gates in the CMTS. 

6.5.1 5.6 Relaying Out of Sync Data 

If a Policy Server discovers during the synchronization process that it is out of sync with a CMTS and that the 
associated data has not yet been forwarded to the Application Manager, then it shall generate a Gate-Report-State for 
the affected gates and send those reports to the appropriate AMs. Creating a Gate-Report-State from a Synch-Report 
should be straightforward since the Synch-Report contains all the objects that are needed in a Gate-Report-State. 

6.5.15.7 Synchronization with Stateless Policy Servers 

Although a stateless policy server has no state, it should still support state synchronization. When an Application 
Manager issues a synchronization request it should be transparent to the AM whether the policy server maintains state. 
This may be implemented by: 

• Translating incoming synchronization requests into synchronization requests to one (or more) of the CMTSs 
with which it is communicating. If a CMTS that is needed to complete the request does not support state 
synchronization (for example, if it is an 102 CMTS) then the PS shall send an error response to the AM with 
error code "State Data Incomplete". 

• Based on those requests it could translate and forward Synch-Report responses back to the AM. 

• If a CMTS is unreachable or a CMTS returns an error then the PS would forward an error response back to the 
AM with error code "Transport Error" or "State Data Incomplete". 

• If all the required CMTSs are reachable and the requests complete successfully, then the synchronization with 
the AM completes successfully. Note that in this situation the PS shall insure that the originating AM receives 
only one Synch-Complete message. 

NOTE: If a stateless policy server loses its TCP connection with a CMTS, there may be some situations where the 
PS may not be able to detect a potential loss of data. For example, if the CMTS does not support 
incremental synchronization the PS will not be able to determine if any Gate Report State messages may 
have been missed. 

6.5.1 6 Procedures for Confirming PDP Receipt of Messages 

Under some circumstances it may be desirable for a PEP to be able to determine if a message has actually been received 
by a PDP. For example, if a PEP implements incremental synchronization, it needs to determine if the PDP has actually 
received a Gate-Report-State message. 

NOTE 1 : Just because it was sent successfully that does not mean that it was received. 

To accomplish this, the PEP may add a Msg Receipt Key to any message sent from the PEP to the PDP. When the PDP 
receives a Msg Receipt Key, it shall send a Msg Receipt message back to the PEP using the same TCP connection. By 
sending back the Msg Receipt Key, the PDP confirms that it has received the message that included that key as well as 
any other messages that preceded it. 

NOTE 2: The PDP shall send a Msg Receipt message for each message it receives with a Msg Receipt Key. 
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It should send the Msg Receipt as soon as it receives the message; it should not delay sending the Msg Receipt until it 
has finished processing the message because the PEP may have resources associated with the request. If a PDP receives 
a message that is invalid (such as a message that cannot be parsed or that does not contain all the required objects), then 
the PDP may silently drop such a message without sending a Msg Receipt. 

The Transaction Identifier in a Msg Receipt message is unused and shall be set to 0. If there are any errors processing a 
Msg Receipt message the PEP shall silently drop the message. 

If a PDP does not send a PDP-Config message for a TCP connection, then the PEP shall not send any Msg Receipt Key 
objects in any messages on that connection. 

The specific contents of the Msg Receipt Key are left to the PEP implementation. It may use any value that best suits 
the PEP implementation and the PDP should make no assumptions about the value. For example, the PEP may choose 
to retransmit unconfirmed Gate-Report-State messages after a certain period of time. Or, the PEP may use this to 
implement an algorithm for tracking delivery in support of incremental synchronization. For example: 

• It could send a Msg Receipt Key in every message it sends to a PDP, or in every n"* message. 

• It could send a Msg Receipt Key based on a periodic interval. 

• It could send a Msg Receipt Key if it has a buffer for storing unconfirmed incremental changes and that buffer 
is approaching its capacity. 

6.5.17 Procedures for Indicating Updated or Lost Sinared Resource 

When Multicast Gates are in use, it is possible that changing conditions may make a single shared resource previously 
used for several Multicast Gates inappropriate for some or all of those Gates. In such a case, the CMTS shall send a 
Gate-Report-State message to the Policy Server for each affected Gate indicating the change, and the Policy Server 
shall in turn forward the message to the Application Manager. 

If the shared resource can be replaced by another instance, then the CMTS shall include Reason value 14 (Gate state 
unchanged, but SharedResourcelD updated) and shall include a new SharedResourcelD value in the message. 

If the shared resource is no longer available and cannot be replaced, then the CMTS shall include Reason value 15 
(close initiated by CMTS due to change of shared resource) and close the associated Gate for each affected 
Gate/Subscriber. 



7 Event Messaging Interface Description 

7.1 Introduction 

As in the IPCablecom 1.x architecture, event messages within IPCablecom Multimedia provide detailed information 
regarding QoS resource utilization, such as reservation, activation, and release. New for the IPCablecom Multimedia 
framework is the need to track status of policy decisions (requests, updates, deletions). Also, since use of network 
resources falls outside the profiles within IPCablecom 1 .x (constant usage over time), there is the need to report 
volume-based and time-based usage information. 

Event messages, as defined in this framework, are generated by network elements and stored on the Record Keeping 
Server (RKS). These EMs are then correlated by the RKS or other back-office system to record a single instance of a 
service. These records may be used to derive service billing information, network resource usage patterns, capacity 
planning, etc. EMs are not, however, intended for fault monitoring. 

Currently, only the CMTS and Policy Server, which are part of the cable operator's network and considered trusted 
entities, generate EMs within the Multimedia framework. Other elements of the network, such as the various client 
types, are considered untrusted. In the case of the Application Manager, this element may or may not be part of the 
cable operator's network, and hence does not directly provide EMs to the RKS. The AM may, however, provide 
supplementary information as part of opaque data fields to the PS which would then be included in EMs generated by 
the PS. 
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IPCablecom event messages for Multimedia represent a simplification and modification of PC 1.x event messages. 
Telephony-specific events such as Call_Answer and Call_Disconnect are considered optional, as are telephony service- 
specific event messages (e.g. Service Instance y). The intent is to leverage existing EM implementations as much as 
possible while providing sufficient abstraction mechanisms to support general Multimedia services. 

Specifically, of the fourteen EM message types defined in support of IPCablecom 1.x voice services, four will be 
required in IPCablecom Multimedia, including QoS_Reserve, QoS_Commit, QoS_Release, and Time_Change. Three 
new EM message types relating to policy decisions are defined; Policy_Request, Policy_Delete, and Policy_Update. 
Table 6 provides a summary overview of the IPCablecom Multimedia EM message types. 

Table 6: IPCablecom Multimedia EM Message Types 



Event 
Message ID 


Event 
Message 


Originating 
Element 


Description 


7 


QoS_Reserve 


CMTS 


Indicates the time at which the CMTS reserves bandwidth on 
the IPCablecom access network. The CMTS must also 
generate this event If the reserved bandwidth changes. 


8 


QoS_Release 


CMTS 


Indicates the time at which the CMTS released Its bandwidth 
commitment on the IPCablecom access network. 


17 


Tinne_Change 


PS, CMTS 


Captures an Instance of a time change. Whenever the 
(IPCablecom) clock on a trusted network element (PS, and 
CMTS) Is changed by more than 200 milliseconds, the 
network element shall generate a Time Change message. 


19 


QoS_Commit 


CMTS 


Indicates the time at which the CMTS commits bandwidth on 
the IPCablecom access network. The CMTS must also 
generate this event If the committed bandwidth changes. 


31 


Policy_Request 


PS 


Indicates the time at which the Policy Server receives a new 
policy request from the AM. 


32 


Policy Delete 


PS 


Indicates the time at which the Policy Server deletes a policy. 


33 


Policy_Update 


PS 


Indicates the time at which the Policy Server receives a 
request to update a policy. 



Although IPCablecom Multimedia event messages are based upon IPCablecom 1 .x, telephony specific events are 
optional for IPCablecom Multimedia and are listed below. For further details on these events and associated attributes 
see the IPCablecom 1.x EM specification [14]. 

Table 7: IPCablecom 1.x Telephony EM Message Types 



Event 
Message ID 


Event 
Message 


Description 


1 


Slgnalllng_Start 


Indicates the time at which signalling starts. 


2 


Slgnalllng_Stop 


Indicates the time at which signalling terminates. 


3 


Database_Query 


Indicates the time at which a one-time request/response transaction or 
database dip Is completed by an Intelligent peripheral (e.g. 800 number 
database, LNP database). 


6 


Servlcejnstance 


Indicates the time at which the CMS provides an Instance of a call 
control/feature service (e.g. call hold, call waiting). 


9 


Servlce_Actlvatlon 


Indicates the time at which the CMS records an attempt to activate a 
service (e.g. call forwarding, call waiting). 


10 


Servlce_Deactlvatlon 


Indicates the time at which the CMS records an attempt to deactivate a 
service (e.g. call forwarding, call waiting). 


13 


lnterconnect_Start 


Indicates the time at which the start of network interconnect signalling 
occurs. 


14 


lnterconnect_Stop 


Indicates the termination of bandwidth between the IPCablecom network 
and the PSTN. 


15 


Call_Answer 


Indicates that the media connection is open because an answer event has 
occurred. 


16 


Call_Dlsconnect 


Indicates the time at which the media connection Is closed because the 
calling party has terminated the call by going on-hook, or that the 
destination party has gone on-hook and the called-party's call-continuation 
timer has expired. 


20 


Medla_Allve 


Indicates that service is active due to the continued existence of a bearer 
connection. This message may be generated by any trusted IPCablecom 
network element (CMS, MGC, and CMTS) as the vendor sees fit. 
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7.2 Record Keeping Server Requirements 

The Record Keeping Server (RKS) is a trusted network element function. The RKS is generally depicted in the present 
document as a distinct standalone element, but the present document does not preclude some other application from 
performing the functions of an RKS, providing that the application conforms to the requirements herein. 

The RKS is the mediation layer between the IPCablecom Multimedia network and the back-office applications. The 
RKS is expected to process the data received from the IPCablecom Multimedia network and to present it to the back- 
office applications in the format and within the time constraints deemed necessary by the cable operator. The RKS 
therefore acts as a demarcation point between the IPCablecom network and the back office applications. 

The RKS shall be capable of receiving and processing Event Messages formatted in accordance with the present 
document. 

The RADIUS messages inside which Event Messages are encapsulated are transported over UDP, which does not 
guarantee reliable delivery of messages; hence the request/response nature of the protocol defined herein. When an RKS 
receives and successfully records all the IPCablecom Event Messages contained in a RADIUS Accounting-Request 
message, it shall transmit an Accounting-Response message to the client. The RKS shall not transmit an Accounting- 
Response reply if it fails to record successfully all the Event Messages in a RADIUS Accounting-Request message. 

The RKS should ignore Event Messages where the IPCablecom "Event Message type" is unrecognized. The RKS 
should also ignore IPCablecom event attributes where the Event Attribute ID is unrecognized. 

7.3 General IPCablecom Multimedia Network Element 
Requirements 

This clause lists requirements placed on the IPCablecom Multimedia network elements. 

7.3.1 Element ID 

Each IPCablecom network element that generates an Event Message shall identify itself with a static, unique element 
ID. The Element ID is a statically configured element number, unique within a IPCablecom domain, which shall be in 
the range to 99,999. 

7.3.2 Timing 

It is important for elements that generate Event Messages to remain closely synchronized with one another and with a 
standard clock. The requirements in this clause ensure that such elements maintain this synchronization and report 
events with timestamps that are both accurate and precise. 

Elements that generate Event Messages shall use the Network Time Protocol as defined in [2]. Elements shall operate in 
mode 3 (Client mode). The value of NTP.MAXPOLL shall not exceed eleven, which corresponds to 2 048 seconds. 

Event Messages shall include timestamps with a precision of one millisecond. 

7.3.3 Primary and Secondary RKS Considerations 

IPCablecom Multimedia supports an architecture that consists of a primary and secondary RKS. The secondary RKS is 
used as a fallback RKS when a network element (PS, CMTS) is unable to successfully send a message to the primary 
RKS. IPCablecom Multimedia network elements shall support event message transport to a primary RKS and failover 
to a secondary RKS when communication with the primary RKS fails. Once a network element fails over to the 
secondary RKS, the secondary becomes the primary for the duration of that session or gate. The Policy Server is 
provisioned with primary and secondary RKSes as required for the applications it supports. The PS shall provide the IP 
address and port of the primary RKS and optionally the secondary RKS to the CMTS in policy decision messages 
(Gate-Set). The PS shall support multiple sets of primary and secondary RKSes. 
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In order to guarantee the reliable transfer of the data the network elements should implement a user configurable retry 
time interval and the number of times the client needs to retransmit the event. The time interval should be configurable 
(suggested: 10 ms to 10 s), the number of retries should be configurable (suggested: to 9). The number of retries 
should be attempted on both the primary RKS and secondary RKS. After exhausting the number of retries the event 
message should be written to an error file, and the event message can then be deleted from the network element. 

If the IPCablecom network element does not receive an Accounting-Response within the configured retry interval, it 
shall continue resending the Accounting-Request until it receives an Accounting-Response from an RKS or the 
maximum number of retries is reached. The IPCablecom network element shall re-send the same Accounting Request to 
the primary RKS and if the retry limit is reached, re-send the same Accounting Request to the secondary RKS. 

All Network Elements shall store Event Messages until they have received an Acknowledgement (Accounting 
Response) from an RKS that the data was correctly received and stored, or until the maximum number of retries has 
been reached. Only when an Ack is received or the maximum retries reached are the network elements allowed to delete 
these Event Messages. 

Once a Network Element succeeds in sending event messages to the secondary RKS, a failover to the secondary RKS 
occurs. This is a non-revertive failover, meaning that the secondary RKS becomes active, and is the new primary RKS. 
All subsequent event messages for the session shall be sent to the now active secondary RKS. For all new sessions, the 
PDF shall instruct the PEP to use the new active RKS as the primary (i.e. the previous secondary RKS becomes the new 
primary for subsequent session). Note that it is possible under certain circumstances that one element, PS or CMTS, 
may be able to communicate with the primary RKS while the other element may not for the same session. In cases such 
as this it is expected that the RKS be able to reconcile event messages between the primary and secondary RKS. 

7.3.4 Interaction with IPCablecom RKS 

An Application Manager may provide an optional Event Generation Info object in the first Gate-Set message to enable 
Event Messaging for the Gate. If the Event Generation Info object is not provided in the first Gate-Set message (by 
either the AM or PS), Event Messaging shall not be used for the life of the Gate. In either case, all subsequently 
supplied Event Generation Info objects for this Gate shall be ignored by the PEP. 

If present, this object shall contain a valid BCID which can be used by the AM, PS, and CMTS to correlate billing 
information for the flow. If an Application Manager provides a BCID to the PS and the AM is trusted by the PS, the PS 
may use the BCID provided by the Application Manager. 

If an Application Manager provides an optional Event Generation Info object which specifies primary and secondary 
RKS IP Addresses that the Policy Server does not have knowledge of, the Policy Server shall send the Event Messages 
for that transaction to the default primary RKS IP Address except in failover circumstances in which case the Event 
Messages shall be sent to the default secondary RKS IP Address. 

The Application Manager may specify a primary RKS IP address in the optional Event Generation Info object or the 
Application Manager may allow the Policy Server to use its default primary and secondary RKS IP Addresses. If the 
AM specifies a primary RKS IP Address, it may also specify a secondary RKS IP Address. The Application Manager 
indicates that an RKS is not specified by setting the primary and secondary RKS IP address and port to zero. 

Regardless of what the Policy Server may receive from the Application Manager, the PS shall direct the CMTS to use 
the same BCID and Primary/Secondary RKS IP Addresses and Ports which the Policy Server chooses to use. The PS 
should decide which RKS pair to send to based on AMID. 

7.4 Event Messages for IPCablecom Multimedia 

This clause provides a detailed description and definition of each of the Event Messages defined for IPCablecom 
Multimedia. 



7.4.1 Policy Events 



The Policy Event Messages are new for IPCablecom Multimedia. They indicate the time at which the Policy Server 
receives a request for a policy action and serve to bracket the ensuing set of Event Messages for any resource usage 
associated with the various instances of a service. Policy event messages are used to indicate the initial policy request, 
an update to the policy, and the deletion of a policy. 
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The PS shall timestamp the Policy Event Messages upon receiving a policy request message from the AM. Immediately 
upon receiving an initial policy request, the PS shall create a Billing Correlation ID (BCID). Each generated BCID shall 
conform to the Billing Correlation ID (BCID) Attribute Structure format requirements in table 18. 

The PS shall include the BCID in the EM header for all subsequently generated Policy Event Messages associated with 
this request. Also, the PS shall include the BCID in the Gate-Set message sent to the CMTS. 

The PS shall generate policy event messages immediately after determining the result of a policy request. The result 
may be based upon PS internal authorization and admission control mechanisms or, upon receiving a response to its 
Gate-Set and Gate-Delete messages from the CMTS. The PS creates a timestamp for an event message when it receives 
a request from the AM but does not generate the event until it knows the outcome of the request. For Multicast Gates, 
the PS additionally indicates the Multicast Classifier and the SharedResourcelD in the policy event messages. 



7.4.1.1 



Policy_Request 



The Policy Server shall send a Policy_Request event message to the RKS if a request to create a new policy is received. 
The PS shall set the Policy_Decision_Status to either Approved (1) or Declined (2), based upon the outcome of 
authorization and admission control. 

NOTE: Because the PS does not send the Policy_Request event message until after the CMTS responds to the 

Gate-Set message, it is possible that QoS event messages from the CMTS may arrive at the RKS prior to 
a Policy-Request event message. 

Table 8: Policy_Request Event Message 



Attribute Name 


Required or 
Optional 


Comment 


Event Message Header 


R 


See table 17. 


Application_Manager_ID 


R 


Contains the network wide unique Application Manager Tag of 
the AM and Application Type. 


SubscriberJD 





If the Gate-Set message contains the SubscriberlD object, the 
PS shall include this in the Event Message. 


IPv6Subscriber_ID 





If the Gate-Set message contains the IPv6SubscriberlD object, 
the PS shall include this in the Event Message. 


Policy_Decision_Status 


R 


1 - Policy Approved. 

2 - Policy Denied. 


Policy_Denied_Reason 





Required when Policy_Decision_Status = 2 (Policy Denied) 
This shall be set to the Error-Code from the IPCablecom Error 
object in the corresponding Gate-Set-Err message, as defined 
in clause 6.4.2.14. 


FEID 


R 


Financial Entity ID. Identifies the paying entity. Supplied by the 
PS. 


AM_Opaque_Data 





If the AM includes the Opaque Data object in the Gate-Set, 
then the PS shall include this in the Event Message. 


Volunne_Usage_Limit 





If the AM includes the Volume-Based Usage Limit object in the 
Gate-Set, then the PS shall include this in the Event Message. 


Time_Usage_Limit 





If the AM includes the Time-Base Usage Limit object in the 
Gate-Set, then the PS shall include this in the Event Message. 


UserJD 





If the AM includes the UserlD object in the Gate-Set, then the 
PS shall include this in the Event Message. 


Multicast Classifier 





Only included for Multicast Gates, if the AM includes a classifier 
in the Gate-Set to a multicast destination address, then the PS 
shall include this in the Event Message. 


SharedResourcelD 





Only included for Multicast Gates, this is the Id returned by the 
CMTS on a successful Gate-Set, the PS shall include this in the 
Event Message. 



7.4.1.2 



Policy_Delete 



The Policy Server shall send a Policy_Delete Event Message to the RKS when it receives a Gate-Delete-Ack from the 
CMTS in response to an AM or PS initiated Gate-Delete, or a Gate-Report-State from the CMTS indicating that the 
resources are no longer available for a session. The PS shall always generate a Policy_Delete Event Message to close a 
session if it has previously generated a Policy-Request Event Message to open the session. 
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Table 9: Policy_Delete Event Message 



Attribute Name 


Required or 
Optional 


Comment 


Event Message Header 


R 


See table 17. 


ApplicationManagerJD 


R 


Contains the network wide unique Application Manager Tag of 
the AM and Application Type. 


SubscriberJD 





If the Gate-Delete-Ack or Gate-Report-State message contains 
the SubscriberJD object, the PS shall include this in the Event 
Message. 


IPv6Subscriber_ID 





If the Gate-Delete-Ack or Gate-Report-State message contains 
the iPvGSubscriberlD object, the PS shall include this in the 
Event Message. 


Policy_Deleted_Reason 


R 


1 - Application Manager request. 

2 - CMTS decision. 
127 -Other. 


FEID 


R 


Financial Entity ID. Identifies the paying entity. Supplied by the 
PS. 


AM_Opaque_Data 





If the Gate-Delete-Ack or Gate-Report-State message contains 
the Opaque Data object, then the PS shall include this in the 
Event Message. 



7.4.1.3 



Policy_Update 



The Policy Server shall send a PolicyUpdate Event Message to the RKS if a request to change the traffic profile, 
classifier, volume limit, time limit, or opaque data of a Gate is received from the AM. Additionally for Multicast Gates, 
if the PS receives an update to the SharedResourcelD from the CMTS, the PS shall send a PolicyUpdate Event Message 
to the RKS with the new SharedResourcelD. 

Table 10: Policy_Update Event Message 



Attribute Name 


Required or 
Optional 


Comment 


Event Message Header 


R 


See table 17. 


Application_ManagerJD 


R 


Contains the network wide unique Application Manager Tag of 
the AM and Application Type. 


SubscriberlD 





If the Gate-Set message contains the SubscriberlD object, the 
PS shall include this in the Event Message. 


IPv6Subscriber_ID 





If the Gate-Set message contains the IPv6SubscriberlD object, 
the PS shall include this in the Event Message. 


Policy_Decision_Status 


R 


1 - Policy Approved. 

2 - Policy Denied. 


Policy_Denied_Reason 





Required when Policy_Decision_Status = 2 (Policy Denied) 
This shall be set to the Error-Code from the IPCablecom Error 
object in the corresponding Gate-Set-Err message, as defined 
in clause 6.4.2.14. 


Policy_Update_Reason 


R 


1 - Traffic Profile. 

2 - Classifier. 

3 - Volume Limit. 

4 - Time Limit. 

5 - Opaque data. 

6 - Multiple Updates (combination of 1-5). 

7 - SharedResourcelD Change. 
127 -Other. 


FEID 


R 


Financial Entity ID. Identifies the paying entity. Supplied by the 
PS. 


AM_Opaque_Data 





If the AM includes the Opaque Data object in the Gate-Set, 
then the PS shall include this in the Event Message. 


Volume_Usage_Limit 





If the AM includes the Volume-Based Usage Limit object in the 
Gate-Set, then the PS shall include this in the Event Message. 


Time_Usage_Limit 





If the AM includes the Time-Base Usage Limit object in the 
Gate-Set, then the PS shall include this in the Event Message. 


UserJD 





If the AM includes the UserlD object in the Gate-Set, then the 
PS shall include this in the Event Message. 
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Attribute Name 


Required or 
Optional 


Comment 


SharedResourcelD 





Only included for Multicast Gates, the PS shall include this in 
the Event Message if the SharedResourcelD has been 
updated. The PS shall use Policy_Update_Reason 7 for this 
purpose. 



7.4.2 QoS Events 

The QoS Event Messages are sent by the CMTS to the RKS and indicate events related to the IPCablecom access 
network resources used by the CMTS. 



7.4.2.1 



QoS Reserve 



This Event Message indicates the time at which the CMTS reserves bandwidth on the IPCablecom access Network. The 
CMTS shall also generate this event if the Reserved bandwidth changes. 

The CMTS shall timestamp this message immediately upon transmission of a DSA-ACK or DSC-ACK acknowledging 
a successful DSA-RSP or DSC-RSP to the CM which completes a transaction reserving resources. 

If the DSA-RSP or DSC-RSP confirmation code from the CM is not successful, the CMTS shall not generate this 

message. 

The CMTS is not required to support Event Messaging for Multicast Gates and the message details are currently not 
defined. At this time the CMTS shall not send a QoS_Reserve message for Multicast Gates. 

For Upstream Drop traffic profiles the CMTS shall set the SF_ID to 0. 

Table 1 1 : QoS_Reserve Event Message 



Attribute Name 


Required or Optional 


Comment 


Event Message Header 


R 


See table 17 


QoS Descriptor 


R 


None 


SF ID 


R 


None 


Flow Direction 


R 


None 


Element_Requesting_QoS 


R 


= Client 

1 = Policy Server 

2 = Embedded Client 



7.4.2.2 



QoS Commit 



The QoS_Commit Event Message indicates the time at which the CMTS commits bandwidth on the IPCablecom access 
Network. The CMTS shall also generate this event if the Committed bandwidth changes. 

The CMTS shall timestamp this message immediately upon transmission of a DSA-ACK or DSC-ACK acknowledging 
a successful DSA-RSP or DSC-RSP to the CM which completes a transaction committing resources. 

If the DSA-RSP or DSC-RSP confirmation code from the CM is not successful, the CMTS shall not generate this 

message. 

For Upstream Drop traffic profiles the CMTS shall set the SF_ID to 0. 

The CMTS is not required to support Event Messaging for Multicast Gates and the message details are currently not 
defined. At this time the CMTS shall not send a QoS_Commit message for Multicast Gates. 
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Table 12: QoS_Commit Event Message 



Attribute Name 


Required or Optional 


Comment 


Event Message Header 


R 


See table 17 


QoS Descriptor 


R 


None 


SFID 


R 


Indicates the Service Flow ID for unicast 
Service Flows 


Flow Direction 


R 


None 



7.4.2.3 



QoS Release 



The QoS_Release Event Message indicates the time at which the CMTS releases its reservation and/or bandwidth 
commitment on the IPCablecom access network. 

The CMTS shall timestamp this message immediately upon Transmission of a DSD-REQ that indicates the request to 
delete bandwidth. 

The CMTS is not required to support Event Messaging for Multicast Gates and message details are currently not 
defined. At this time the CMTS shall not send a QoS_Release message for Multicast Gates. 

Table 13: QoS_Release Event Message 



Attribute Name 


Required or Optional 


Comment 


Event Message Header 


R 


See table 17 


SFID 


R 


None 


Flow Direction 


R 


None 


QoS_Release_Reason 


R 


1 - Gate Closed by PS 

2 - Inactivity resource recovery (T4) timer expiration 

3 - CM Failure 

4 - Pre-Empted 

5 - RSVP Pathlear request 

6 - CM request 

7 - Admitted (12) timer expiration 
1 27 - Other 


Gate Usage Info 


R 


None 


Gate Time Info 


R 


None 



7.4.3 Time_Change 

This event captures an instance of a time change. Whenever the (IPCablecom) clock on the network element (PS or 
CMTS) is changed by more than 200 milliseconds, the network element shall generate a Time Change message. This 
includes time shift events (Daylight savings time), step adjustments to synchronize with the NTP reference clock and 
manual time setting changes. The Event_Time attribute in the Event Message header shall reflect the new (adjusted) 
notion of time. Note that Time_Change message is not required for slew adjustments performed by NTP. 

The network element (PS and CMTS) shall send the Time Change event message to the active (current primary) RKS. 
The Time Change event message shall be generated when a gate(s) is currently present in the CMTS. The Time Change 
event message need not be generated when there are no gates in the CMTS. Only one Time Change event message is 
sent to each primary RKS regardless of how many gates may exist on the CMTS. In other words, if the CMTS has 
several gates all of which point to the same RKS, then only one Time Change event message should be sent to that 
RKS. 

The BCID in the Event Message Header of the Time Change event message shall be generated locally by the network 
element at the time of the event. The BCID is not associated with any session related BCID, it is a unique BCID for this 
event. 

Table 14: Time_Change Event Message 



Attribute Name 


Required or Optional 


Comment 


Event Message Header 


R 


See table 17 


Time_Adjustment 


R 


None 
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7.5 Event Messaging Attributes for IPCablecom IVIultimedia 

This clause describes and defines the IPCablecom attributes included in the IPCablecom Event Messages. 

Table 15 provides a mapping between each of the IPCablecom Event Messages and their associated attributes. Table 16 
offers a detailed description of each of these attributes. 

Table 15: IPCablecom Attributes Mapped to IPCablecom MM Event Messages 
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Event Message Header 


X 


X 


X 


X 


X 
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X 


30 


SF ID 


X 


X 




X 








32 


QoS Descriptor 


X 






X 








38 


Time Adjustment 






X 










49 


FEID 










X 


X 


X 


50 


Flow Direction 


X 


X 




X 








61 


AlVl Opaque Data 










X 


X 


X 


62 


Subscriber ID 










X 


X 


X 


63 


Volume Usage Limit 










X 




X 


64 


Gate Usage Info 




X 












65 


Element Requesting Qos 


X 














66 


QoS Release Reason 




X 












67 


Policy Denied Reason 










X 




X 


68 


Policy Deleted Reason 












X 




69 


Policy Update Reason 














X 


70 


Policy Decision Status 










X 




X 


71 


Application Manager ID 










X 


X 


X 


72 


Time Usage Limit 










X 




X 


73 


Gate Time Info 




X 












74 


IPv6Subscriber ID 










X 


X 


X 


75 


User ID 










X 




X 


77 


Multicast Classifier 










X 


X 


X 


78 


SharedResourcelD 










X 


X 


X 



Table 16 provides a detailed definition of each of the IPCablecom Event Message attributes. A data value of an attribute 
may either be represented by a simple data format (one data field) or by a more complex data structure. 

Table 16: IPCablecom MM Event Message attributes 



EM 

Attribute 

ID 


EM 

Attribute 

Length 


EM Attribute Name 


EM Attribute 
Value Type 


Attribute Data Description 


1 


76 bytes 


EMHeader 


Data structure 
See table 1 7 


Common data required on every 
IPCablecom Event Message. 


30 


4 bytes 


SFJD 


Unsigned 
integer 


Service Flow ID, a 32-bit integer assigned 
by the CMTS to each DOCSIS Service Flow 
defined within a DOCSISRF MAC domain. 
SFIDs are considered to be in either the 
upstream direction (USFID) or downstream 
direction (DSFID). USFIDs and DSFIDs are 
allocated from the same SFID number 
space. 


32 


Variable; 
Min 8 bytes 


QoS_Descriptor 


Data structure 
See table 20 


QoS parameters data. 
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EM 

Attribute 

ID 


EM 

Attribute 

Length 


EM Attribute Name 


EM Attribute 
Value Type 


Attribute Data Description 


38 


8 bytes 


Time_Adjustment 


Signed integer 


Time adjustment of an element's (PS, 
CMTS) clock. 

This time is in milliseconds, detailing the 
amount of the time change. 


49 


Variable 
length, 
maximum 
of 247 
bytes 


FEID 


ASCII 

character 

string. 


Financial Entity ID. The first 8 bytes 
constitute cable operator defined data. By 
default, the first 8 bytes are zero filled. From 
the 9"^ byte on the field contains the cable 
operator's domain name which uniquely 
identifies the cable operator for billing and 
settlement purposes. The cable operator's 
domain name is limited to 239 bytes. 


50 


2 bytes 


Flow Direction 


Unsigned 
integer 


Flow direction: 

= Reserved 

1 = Upstream 

2 = Downstream 


61 


8 bytes 


AM_Opaque_Data 


Unsigned 
integer 


Opaque data passed from Application 
IVIanager. 


62 


4 bytes 


SubscriberJD 


Unsigned 
integer 


4 concatenated byte values representing an 
IPv4 address. 


63 


8 bytes 


Volume_Usage_Limit 


Unsigned 
integer 


Volume limit in octets set by the AM. 


64 


8 bytes 


Gate_Usage_lnfo 


Unsigned 
integer 


The number of octets transmitted on the 
DOCSIS RF network from the byte after the 
MAC header HCS to the end of the CRC. 


65 


2 bytes 


Element_Requesting_QoS 


Unsigned 
integer 


= Client 

1 = Policy Server 

2 = Embedded Client 


66 


2 bytes 


QoS_Release_Reason 


Unsigned 
integer 


1 - Gate Closed by PS 

2 - Inactivity resource recovery (T4) timer 
expiration 

3 - CM Failure 

4 - Pre-Empted 

5 - RSVP PathTear request 

6 - CM request 

7 - Admitted (T2) timer expiration 
127 -Other 


67 


2 bytes 


Policy_Denied_Reason 


Unsigned 
integer 


The Error-Code from the IPCablecom Error 
object in the corresponding Gate-Set-Err 
message, as defined in clause 6.4.2.14. 


68 


2 bytes 


Policy_Deleted_Reason 


Unsigned 
integer 


1 - Application Manager request 

2 - CMTS decision 
127 -Other 


69 


2 bytes 


Policy_Update_Reason 


Unsigned 
integer 


1 - Traffic Profile 

2 - Classifier 

3 - Volume Limit 

4 - Time Limit 

5 - Opaque data 

6 - Multiple Updates (combination of 1-5) 
127 -Other 


70 


2 bytes 


Policy_Decision_Status 


Unsigned 
integer 


1 - Policy Approved 

2 - Policy Denied 


71 


4 bytes 


Application_Manager_ID 


Unsigned 
integer 


Application Manager ID, composed of 
Application Manager Tag and Application 
Type, as defined in clause 6.4.2.2. 


72 


4 bytes 


Time_Usage_Limit 


Unsigned 
integer 


Time limit in seconds set by the AM. 


73 


4 bytes 


Gate_Time_lnfo 


Unsigned 
integer 


The number of seconds a gate has been in 
either the Committed or Committed- 
Recovery states. 
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EM 

Attribute 

ID 


EM 

Attribute 

Length 


EM Attribute Name 


EM Attribute 
Value Type 


Attribute Data Description 


74 


1 6 bytes 


IPv6Subscriber_ID 


Unsigned 
integer 


1 6 concatenated byte values representing 
an IPv6 address. 


75 


Variable 


UserlD 


UTF-8 

character 

string 


Character string identifying the user 
associated with reported Event. 


76 


Variable 
(24, 40, 64 
bytes) 


Multicast Classifier 


Data structure 

See 

clause 6.4.2.6 

Classifiers 


Classifier information, required for Multicast 
Gates only. This is the Classifier, or 
Extended Classifier, or the IPv6 classifier 
object defined for a Multicast Gate. 


11 


4 bytes 


SharedResourcelD 


Unsigned 
integer 


The Shared Resource Identifier is a 4-byte 
unsigned integer value assigned by the 
CMTS only for Multicast Gates. 



7.5.1 EM_Header Attribute Structure 

Table 17 contains a detailed description of the fields in the EM_Header attribute structure. This Event Message Header 
attribute shall be the first attribute in every IPCablecom Event Message. 

Table 17: EM Header Attribute Structure 



Field Name 


Semantics 


Value Type 


Length 


VersionJD 


Identifies version of this EM Header structure. 

1 = IPCablecom 1.0 

2 = IPCablecom 1.1 

3 = IPCablecom Multimedia 
(See note). 

The PS and CMTS network elements shall set the value of 
the Version ID to 3. 


Unsigned integer 


2 bytes 


BCID 


Unique identifier for a transaction within a network. 


Data Structure 
See table 18 


24 bytes 


Event Message Type 


Identifies the type of Event Message. 


Unsigned integer 


2 bytes 


Element Type 


Identifies Type of Originating Element: 

= Reserved 

1 = Reserved 

2 = CMTS 

3 = Reserved 

4 = Policy Server 


Unsigned integer 


2 bytes 


Element ID 


Network wide unique identifier 

5 digits (statically configured element number unique within a 

IPCablecom domain in the range of 0-99,999) 


Right justified, 
space padded 
ASCII Character 
String 


8 bytes 


Time Zone 


Identifies daylight savings time and offset from universal time 

(UTC). 

Daylight Savings Time: 

= Standard Time 

1 = Daylight Savings 

The Daylight-Savings Time indicator shall be set to a value of 
1 if the network element is in a region that implements DST 
and then only during the daylight-saving-time period (usually 
the summer months). Since there may be areas in which the 
daylight-saving-time offset indicates a time-change other than 
1 hour, the receiving system (e.g. RKS) needs to correctly 
calculate local time based on knowledge of the area(s) in 
which the subscriber and the network element reside. 
UTC offset: ± HHMMSS 
The offset is reported from the network element 
(PS, CMTS) point of view; not based on the subscriber point 
of view. 

The UTC offset represents the time offset from universal time 
(formerly called Greenwich Mean Time, or GMT) when 
standard time is in effect and shall not change on transition 
into or out of daylight-saving-time. 


ASCII character 
string 


1 byte 
7 bytes 
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Field Name 


Semantics 


Value Type 


Length 




For example: The Time_Zone field of a network element in 
Boston in December is "0-050000". The same network 
element in Boston in July is "1-050000". 






Sequence Number 


Each network element shall assign a unique and 
monotonically increasing unsigned integer for each Event 
Message sent to a given RKS. For the purpose of the present 
document, monotonically increasing is to be interpreted as 
increasing by 1 . This is used by the RKS to determine if Event 
Message are missing from a given network element. 


Unsigned integer 


4 bytes 


EvenMime 


Event generation time and date. Millisecond granularity. This 
specifies the local time. i.e. after applying Time_Zone UTC 
offset and Daylight Savings Time adjustment to UTC time. 
Format: yyyymmddhhmmss.mmm 


ASCII character 
string 


18 bytes 


Status 


Status indicators 


See table 19 


4 bytes 


Priority 


Indicates the importance to assign relative to other event 

messages. 

255 = highest priority 

= lowest priority 

128 = default. 


Unsigned integer 


1 byte 


Attribute Count 


Indicates the number of attributes that follow (or are 
appended to) this header in the current Event Message. 


Unsigned integer 


2 bytes 


Event_ObjeGt 


The Event_Object field allows for a grouping of 
services. 

= Accounting Event Message 

1 = Reserved 

The PS and CMTS network elements shall set the value of 
the Event_Object field to if the EM_Header VersionJD is 3 
(IPCablecom Multimedia Event Message to the RKS). 
The RKS shall discard EM messages when the Event_Object 
field is set to 1 . 


Unsigned integer 


1 byte 


NOTE: A value of 2 or 3 indicates tine Event_Object field in this header is used. 



7.5.2 Billing Correlation ID (BCID) Field Structure 

Table 18 describes the Billing Correlation ID field (BCID). The RKS, or some other back office application, uses the 
BCID to correlate Event Messages that are generated for a single transaction. It is one of the fields in the Event 
Message Header Attribute. The BCID is unique for each transaction in the network. All Event Messages from the same 
network element with the same BCID shall be sent to the same primary RKS except in failover circumstances in which 
case the Event Messages shall be sent to secondary RKS. 
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Table 18: BCID Field Description 



Field Name 


Semantics 


Value Type 


Length 


Timestamp 


High-order 32 bits of NTP time reference 


Unsigned integer 


4 bytes 


ElementJD 


Networl< wide unique identifier 

5 digits (statically configured element number unique 

within a IPCablecom domain in the range of 0-99,999) 


Right justified, space 
padded ASCII character 
string 


8 bytes 


Time Zone 


Identifies daylight savings time and offset from universal 

time (UTC). 

Daylight Savings Time: 

= Standard Time 

1 = Daylight Savings 

The Daylight-Savings Time indicator shall be set to a value 
of 1 if the network element is in a region that implements 
DST and then only during the daylight-saving-time period 
(usually the summer months). Since there may be areas in 
which the daylight-saving-time offset indicates a time- 
change other than 1 hour, the receiving system (e.g. RKS) 
needs to correctly calculate local time based on 
knowledge of the area(s) in which the subscriber and the 
network element reside. 
UTC offset: + HHMMSS 

The offset is reported from the network element (PS, 
CMTS) point of view; not based on the subscriber point of 
view. 

The UTC offset represents the time offset from universal 
time (formerly called Greenwich Mean Time, or GMT) 
when standard time is in effect and shall not change on 
transition into or out of daylight-saving-time. 
For example: The Time_Zone field of a network element in 
Boston in December is "0-050000". The same network 
element in Boston in July is "1-050000". 


ASCII character string 


1 byte 
7 bytes 


Event Counter 


Monotonically increasing for each Transaction 


Unsigned integer 


4 bytes 



7.5.3 Status Field Structure 

The Status field of the Event Message Header Attribute is a 32-bit mask. Bit is the low-order bit; the field is treated as 
a 4 byte unsigned integer. Table 19 presents Status field description. 

Table 19: Status Field Description 



Start Bit 


Semantics 


Bit Count 


0-1 


Error Indicator: 

= No Error 

1 = Possible Error 

2 = Known Error 

3 = Reserved 


2 


2 


Event Origin: 

= Trusted Element 

1 = Untrusted Element 


1 


3 


Event Message Proxied: 

= Not proxied, all data known by sending element 

1 = proxied, data sent by a trusted element on behalf of an untrusted element 


1 


4-31 


Reserved. 

The Status field bits 4 to 31 shall be set to 0. 


28 
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7.5.4 QoS Descriptor Attribute Structure 

Table 20 describes the QoS Descriptor Data Structure. 

Table 20: QoS Descriptor Data Structure 



Field Name 


Semantics 


Value Type 


Length 


Status_Bitnnask 


Bitmask describing structure 
contents (see table 21) 


Bit map 


4 bytes 


Service_Class_Name 


Service profile name 


Right justified, space 
padded ASCII character 
string 


1 6 bytes 


QoS_Paranneter_Array 


QoS Parameters. Contents 
determined by Status Bitmask 


Unsigned integer array 


Variable length array of 
32-bit unsigned integers 



Table 21 describes the QoS Status Bitmask field of the QoS Descriptor attribute. Bits 2-17 describe the contents of the 
QoS_Parameter_Array. Each of these bits indicates the presence (bit=l) or absence (bit=0) of the named QoS parameter 
in the array. The location of a particular QoS parameter in the array matches the order in which that parameter's bit is 
encountered in the bitmask, starting from the low-order bit. 

Each QoS parameter present in the QoS_Parameter_Array must occupy four bytes. The definition and encoding of the 
QoS parameters can be found in annex C of the [1] specification. QoS parameters whose definition specifies less than 
four bytes must be right -justified (where the 4 bytes are to be treated as an unsigned integer) in the four bytes allocated 
for the array element. 

Table 21 : QoS Status Bitmask 



Start Bit 


Semantics 


Bit Count 





State Indication: 

= Illegal Value 

1 = Resource Reserved but not Activated 

2 = Illegal Value 

3 = Resource Reserved & Activated 


2 


2 


Service Flow Scheduling Type 




3 


Nominal Grant Interval 




4 


Tolerated Grant Jitter 




5 


Grants Per Interval 




6 


Unsolicited Grant Size 




7 


Traffic Priority 




8 


Maximum Sustained Rate 




9 


Maximum Traffic Burst 




10 


Minimum Reserved Traffic Rate 




11 


Minimum Packet Size 




12 


Maximum Concatenated Burst 




13 


Request/Transmission Policy 




14 


Nominal Polling Interval 




15 


Tolerated Poll Jitter 




16 


IP Type of Service Overwrite 




17 


Maximum Downstream Latency 




18 


Downstream Peak Traffic Rate 




19 


Provisioned Attribute Mask 




20 


Required Attribute Mask 




21 


Forbidden Attribute Mask 




22 


Attribute Aggregation Rule Mask 





7.6 RADIUS Accounting Protocol 



This clause specifies the protocol used between the IPCablecom network elements that generate Event Messages (PS, 
CMTS) and the Record Keeping Server (RKS). These network elements shall support RADIUS Accounting 
(RFC 2866 [11]) with IPCablecom extensions as defined in the present document. 
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The RADIUS Accounting protocol is a client/server protocol that consists of two message types: Accounting-Request 
and Accounting-Response. IPCablecom network elements that generate Event Messages are RADIUS clients that send 
Accounting -Request messages to the RKS. The RKS is a RADIUS server that sends Accounting-Response messages 
back to the IPCablecom network elements indicating that it has successfully received and stored the Event Message. 

The Event Messages are formatted as RADIUS Accounting-Request and Accounting-Response packets as specified in 
[11]- 



7.6.1 Authentication and Confidentiality 



Refer to clause 8 for details concerning the use of IPsec to provide both authentication and confidentiality of the 
RADIUS messages, and the details of the correct usage of the RADIUS shared secret. 

7.6.2 Standard RADIUS Attributes 

Each RADIUS message starts with the standard RADIUS header shown in table 22. 

Table 22: RADIUS Message Header 



Field Name 


Semantics 


Field Length 


Code 


Accounting-Request = 4 
Accounting-Response = 5 


1 byte 


Identifier 


Used to match accounting-request and accounting-response messages. 


1 byte 


Length 


Total length of RADIUS message 
min value = 20 
max value = 4096 


2 bytes 


Autlienticator 


Computed as per RADIUS Specification 


1 6 bytes 



Two standard RADIUS attributes shall follow the RADIUS Message Header: NAS-IP-Address and Acct_Status_Type. 
These two fields are included to improve interoperability with existing RADIUS server implementations since they are 
mandatory attributes in a RADIUS Accounting-Request packet. 

The NAS-IP-Address indicates the originator of the Accounting-Request message and shall contain the IP address of 
the originating IPCablecom network element. 

The Acct-Status-Type attribute typically indicates whether the Accounting-Request marks the beginning of the user 
service (Start) or the end (Stop). A IPCablecom Accounting-Request message may contain the beginning, end, or 
update of the user service. For this reason, an Acct-Status-Type value of Interim-Update is used to represent 
IPCablecom Event Messages. 

Table 23: Mandatory RADIUS Attributes 



Name 


Type 


Length 


Value 


NAS-IP-Address 


4 


6 


IP address of originating IPCablecom network element 


Acct-Status-Type 


40 


6 


Interim-Update = 3 



Table 24: RADIUS Acct_Status_Type 



Type 


Length 


Value 


40 


6 bytes 


Interim-Update = 3 



IPCablecom attributes are encoded in the RADIUS Vendor Specific Attributes (VSA) structure as described in this 
clause. Additional IPCablecom or vendor-specific attributes can be added to existing Event Messages by adding 
additional RADIUS VSAs to the message. 

The Vendor-Specific attribute includes a field to identify the vendor, and the Internet Assigned Numbers Authority 
(IAN A) has assigned IPCablecom an SMI Network Management Private Enterprise Number of 4491 for the encoding 
of these attributes. 
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Table 25: Radius VSA Structure for IPCablecom Attributes 



Field Name 


Semantics 


Field Length 


Type 


Vendor Specific = 26 


1 byte 


Length 


Total Attribute Length 
(See note 1) 


1 byte 


Vendor ID 


CableLabs = 4491 


4 bytes 


Vendor Attribute Type 


IPCablecom Attribute Type 


1 byte (see table 16) 


Vendor Attribute Lengtii 


IPCablecom Attribute Length 


1 byte (see table 1 6) 
(See note 2) 


Vendor Attribute Value 


IPCablecom Attribute Value 


Vendor Length bytes 


NOTE 1 : Value is Vendor Length + 8. 
NOTE 2: Value is Vendor Length + 2. 



7.6.3 IPCablecom RADIUS Accounting-Request Packet Syntax 

<<RADIUS Accounting-Request> : : == 

<RADIUS message Header> 
<RADIUS NAS- IP-Address Attribute> 
<RADIUS Acct-Status-Type Attribute> 
<IPCablecom EM> 



<IPCablecom EM> 



<RADIUS VSA for IPCablecom EM Header Attribute> 
<IPCablecom EM Attribute List> 



<IPCablecom EM Attribute List> ::== 

<RADIUS VSA for IPCablecom EM Attribute> | 

<IPCablecom EM Attribute List> 

<RADIUS VSA for IPCablecom EM Attribute> 

The Event Message Header is the first attribute within a given Event Message. The order of the Event Message 
attributes which follow the Event Message Header is arbitrary. 



8 



Security Requirements 



Security for IPCablecom Multimedia interfaces utilizes security mechanisms defined in [16] as well as in [1]. Table 26 
provides a summary of security mechanisms for each of the IPCablecom Multimedia interfaces. 

Table 26: IVIultimedia Security Interfaces 



Interface 


Description 


Security Mechanisms 


pkt-mm-1 


CMTS - CM 


HMAC-based authentication defined by the 
DOCSIS specification [1]. 


pkt-mm-2 


PS - CMTS 


IPsec ESP using IKE or Kerberos-based key 
management. 


pkt-mm-3 


AM -PS 


IPsec ESP using IKE or Kerberos-based key 
management. 


pkt-mm-4 


PS - RKS 


IPsec ESP using IKE or Kerberos-based key 
management. 


pkt-mm-5 


CMTS - RKS 


IPsec ESP using IKE or Kerberos-based key 
management. 


pkt-mm-6 


Client - CMTS 


Out of scope for the present document. 


pkt-mm-7 


Client -AM 


Out of scope for the present document. 


pkt-mm-8 


AM - Peer 


Out of scope for the present document. 


pkt-mm-9 


CMTS - cable operator-Managed IP Network 


Out of scope for the present document. 


pkt-mm-1 


Client - Peer 


Out of scope for the present document. 



The following clauses describe security that is applied to each IPCablecom Multimedia interface and specify additional 
requirements or extensions whenever necessary. 
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8.1 CMTS - CM QoS Interface (pkt-mm-1) 

DOCSIS QoS messages are authenticated using an HMAC (Hash Message Authentication Code), which is a keyed 
cryptographic hash. Calculation of the HMAC attribute that must be included in DOCSIS QoS messages is specified in 
clause C.l of [1]. 

8.2 Policy Server - CMTS COPS Interface (pkt-mm-2) 

The Policy Server - CMTS COPS interface shall be secured using the IPsec ESP protocol, as specified in 
clause 7.2.1.3.2 of [16]. The key management requirements for this interface shall comply with clause 7.2.1.4.1 of [16]. 
For this interface. Policy Server shall comply with all the Gate Controller requirements listed in clauses 7.2.1.3.2 and 
7.2.1.4.1 of [16]. IKE with pre-shared keys is required to implement, while IKE with certificates and Kerberized IPsec 
are both optional to implement. 

In the case that Kerberized IPsec is utilized, clause 6.4.5 of [16] defines principal names of various Kerberized services. 
The first component of a principal name is unique for each type of a Kerberized service. Clause 6.4.5 of [16] already 
specifies the first component of the CMTS's principal name. The first component of Policy Server's principal name shall 
be: 

policyserver:<ElementID> 

where <ElementID> is defined in clause 6.4.5 of [16]. 

In the case that IKE with certificates is utilized, the subject name in a server certificate has the following attribute 
defined in clause 8.2.3.4.3 of [16]: 

OU=<Sub-System Name> 

The value of <Sub-System Name> identifies a server type. The value of <Sub-System Name> for a CMTS is already 
specified in clause 8.2.3.4.3 of [16]. The value of <Sub-System Name> for a Policy Server shall be the following string: 
policyserver. 

8.3 Application Manager - Policy Server COPS Interface 
(pkt-mm-3) 

The Application Manager - Policy Server COPS interface shall be secured using the IPsec ESP protocol, as specified in 
clause 7.2.1.3.2 of [16]. The key management requirements for this interface shall comply with clause 7.2.1.4.1 of [16]. 
For this interface. Application Manager shall comply with all the Gate Controller requirements listed in 
clauses 7.2.1.3.2 and 7.2.1.4.1 of [16]. IKE with pre-shared keys is required to implement, while IKE with certificates 
and Kerberized IPsec are both optional to implement. 

In the case that Kerberized IPsec is utilized, clause 6.4.5 of [16] defines principal names of various Kerberized services. 
The first component of a principal name is unique for each type of a Kerberized service. The first component of Policy 
Server's principal name is specified in clause 8.2 of the present document. The first component of Application 
Manager's principal name shall be: 

am:<ElementID> 

where <ElementID> is defined in clause 6.4.5 of [16]. 

In the case that IKE with certificates is utilized, the subject name in a server certificate has the following attribute 
defined in clause 8.2.3.4.3 of [16]: 

OU=<Sub-System Name> 

The value of <Sub-System Name> identifies a server type. The value of <Sub-System Name> for a Policy Server is 
specified in clause 8.2 of the present document. The value of <Sub-System Name> for an Application Manager shall be 
the following 2-character string: am. 
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8.4 Policy Server - RKS Event Message Interface (pkt-mm-4) 

The Policy Server - RKS Event Message interface shall be secured using the IPsec ESP protocol, as specified in 
clause 7.3.2 of [16]. The key management for this interface shall be identical to the one specified for a CMTS-RKS 
interface in clause 7.3.3.2 of [16]. IKE with pre-shared keys is required to implement, while IKE with certificates and 
Kerberized IPsec are both optional to implement. 

In the case that Kerberized IPsec is utilized, clause 6.4.5 of [16] defines principal names of various Kerberized services. 
The first component of a principal name is unique for each type of a Kerberized service. Clause 6.4.5 of [16] already 
specifies the first component of the RKS's principal name. The first component of Policy Server's principal name is 
specified in clause 8.2 of the present document. 

In the case that IKE with certificates is utilized, the subject name in a server certificate has the following attribute 
defined in clause 8.2.3.4.3 of [16]: 

OU=<Sub-System Name> 

The value of <Sub-System Name> identifies a server type. The value of <Sub-System Name> for an RKS is already 
specified in clause 8.2.3.4.3 of [16]. The value of <Sub-System Name> for a Policy Server is specified in clause 8.2 of 
the present document. 

8.5 CMTS - RKS Event Message Interface (pkt-mm-5) 

The CMTS - RKS Event Message interface shall be secured using the IPsec ESP protocol, as specified in clause 7.3.2 of 
[16]. The key management for this interface is specified in clause 7.3.3.2 of [16]. IKE with pre-shared keys is required 
to implement, while IKE with certificates and Kerberized IPsec are both optional to implement. 



9 Mapping a FlowSpec Traffic Profile to DOCSIS 

A Traffic Profile defines the QoS attributes of the IP flow or the DOCSIS Service Flow to be used in performing 
authorization, reservation and commit operations. A Traffic Profile can be defined via one of the following methods: 

• FlowSpec 

• DOCSIS Service Class Name 

• DOCSIS Specific Parameterization 

• Upstream Drop 

This clause describes the mapping procedures for deriving the DOCSIS-specific QoS parameters from the various 
Traffic Profile representations, excluding Upstream Drop. A Traffic Profile may include the authorization, reservation 
or commit envelopes. As defined in [4], a FlowSpec consists of a TSpec and an optional RSpec. 

9.1 Mapping FlowSpecs to DOCSIS Scheduling Types 

FlowSpecs support two types of services: Controlled Load and Guaranteed. Controlled Load services provide minimum 
bandwidth guarantees, but not latency/delay guarantees. Guaranteed services provide both bandwidth and latency/delay 
guarantees. Guaranteed service may be closely approximated through DOCSIS Real-Time Polling and UGS scheduling 
types. Controlled Load service may be closely approximated through the DOCSIS Best-Effort scheduling type. The 
FlowSpec service number in the FlowSpec definition distinguishes between Controlled Load and Guaranteed services. 
Service number 5 indicates the definition is for Controlled Load service, and service number 2 indicates the definition is 
for Guaranteed service. Further, Controlled Load service contains only the TSpec token bucket parameters, but not the 
RSpec. Guaranteed service shall contain both the TSpec and the RSpec. 
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For latency and jitter-sensitive applications such as voice, MPEG video or gaming, one could request Guaranteed 
service. The CMTS can then use the traffic profile parameters specified in the FlowSpec to select one of the two types 
of DOCSIS scheduling types that could provide Guaranteed service: RTFS and UGS. For other applications that are not 
latency sensitive one could request Controlled Load service, which can be used to provide minimum bandwidth 
guarantees. Table 27 summarizes the choices. 

Table 27: Mapping FlowSpecs Types 



DOCSIS Scheduling Type 


FlowSpec Service Number 


Application Example 


Unsolicited Grant Service (UGS) 


2 (Guaranteed) 


Voice over IP 


Real-Time Polling Service (RIPS) 


2 (Guaranteed) 


VPN 


Best Effort (BE) 


5 (Controlled Load) 


Best Effort Internet Data 



The general FlowSpec-to-DOCSIS mapping procedure for upstream service flows is as follows: 

• Upon receipt of a Gate-Set message with a FlowSpec the CMTS shall analyzes the TSpec Service Header to 
determine whether Controlled load or Guaranteed service is being requested. 

• If Controlled Load Service, then the CMTS shall use only the TSpec parameters to resolve the DOCSIS 
scheduling parameters to define the DOCSIS Traffic Parameters for a DOCSIS Best-Effort Scheduling type. 

• If Guaranteed Service, the CMTS shall examine the TSpec and RSpec parameters and use either UGS or RTFS 
scheduling types based on their definitions in clauses 9.3.1 and 9.3.2 respectively. 

• If the Reserved Rate (R) and Bucket Rate (r) are not equal, then the CMTS shall use the TSpec and the RSpec 
to define the DOCSIS Traffic Parameters for a DOCSIS Real-Time Polling scheduling type. 

Note that two other types of DOCSIS scheduling types are not mentioned above. These are: 

• Unsolicited Grant Service with Activity Detection 

• Non-Real-Time Polling Service 

If the Application Manager wishes to request either one of these services, it can only do so by using either the Service 
Class Name or the DOCSIS-specific parameterization method of defining the Traffic Profile. 

9.2 Mapping FlowSpecs to DOCSIS Traffic Parameters 

The FlowSpec is made up of two parts, the TSpec and the RSpec. The TSpec describes the traffic for the flow, and the 
RSpec describes the desired service; note that for a controlled load service, the RSpec is not used. The RSpec 
parameters shall be specified for a guaranteed service. The CMTS shall ignore the RSpec parameters for a controlled 
load service. The RSpec is used to provide latency guarantees for guaranteed services. Please refer to RFC 2210 [4], 
RFC 2211 [5] and RFC 2212 [6] for more information on how these parameters should be used by Application 
Managers to specify the traffic profile. Note that the IPCablecom Multimedia interpretation of Flowspecs differs from 
the RFCs in the following respects: 

• Guaranteed Service as defined in [5] controls Layer 3 queuing delay (i.e. the delays associated with packet 
scheduling), whereas in IPCablecom Multimedia we are primarily concerned with controlling the access delay 
of the DOCSIS MAC layer. Consequently we reserve bandwidth resources according to the Tspec's r 
parameter rather than the Rspec's R. 

• As defined in [4], Controlled Load service defines only a guaranteed minimum rate for a flow. IPCablecom 
Multimedia's Controlled Load service facilitates definition of the maximum rate for a flow, as well as 
definition of flows without a guaranteed minimum rate. 

• The Guaranteed Service Slack Term parameter is not need in IPCablecom Multimedia, so the field is redefined 
to enable control of DOCSIS polling jitter. 

TSpec Parameters: 

• Bucket Depth (b), bytes 

• Bucket Rate (r), bytes/second 
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• Maximum Datagram Size (M), bytes 

• Minimum Policed Unit (m), bytes 

• Peak Rate (p), bytes/second 
RSpec Parameters: 

• Reserved Rate (R), bytes/second 

• Slack Term (S), microseconds 

The parameter mapping, roughly approximated, involves the following associations for DOCSIS upstream BE (Best- 
Effort) and downstream Controlled Load Service Flows. The actual mapping procedure would involve normalizing 
these parameters to account for Layer 2 and Layer 3 header considerations. 

• TSpec Bucket Depth (b) ~= DOCSIS Maximum Traffic Burst 

• TSpec Maximum Datagram Size (M) ~= <not required by DOCSIS > 

• TSpec Minimum Policed Unit (m) ~= DOCSIS Assumed Minimum Reserved Rate Packet Size 

• TSpec Bucket Rate (r) ~= DOCSIS Minimum Reserved Rate 

• TSpec Peak Rate (p) ~= DOCSIS Maximum Sustained Rate and, for DOCSIS 3.0 only, DOCSIS Downstream 
Peak Traffic Rate 

For downstream Guaranteed service flows, the RSpec parameters are added to provide latency and reservation 
guarantees. 

• TSpec Bucket Depth (b) ~= DOCSIS Maximum Traffic Burst 

• TSpec Maximum Datagram Size (M) ~= <not required by DOCSIS > 

• TSpec Minimum Policed Unit (m) ~= DOCSIS Assumed Minimum Reserved Rate Packet Size 

• TSpec Bucket Rate (r) ~= DOCSIS Minimum Reserved Rate and DOCSIS Maximum Sustained Rate 

• TSpec Peak Rate (p) ~= For DOCSIS 3.0 only, DOCSIS Downstream Peak Traffic Rate 

• RSpec Reserved Rate (R) ~= <not required by DOCSIS> 

• RSpec Slack Term ~= DOCSIS Downstream Latency 

The parameter mapping, roughly approximated, involves the following associations for DOCSIS UGS Service Flows. 

• TSpec Bucket Depth (b) = TSpec Maximum Datagram Size (M) = TSpec Minimum Policed Unit (m) ~= 
DOCSIS UnsoHcited Grant Size 

• TSpec Bucket Rate (r) = TSpec Peak Rate (p) = RSpec Reserved Rate (R) ~= used to calculate Nominal Grant 
Interval 

• RSpec Slack Term ~= DOCSIS Tolerated Grant Jitter 

Similarly, the following associations apply for DOCSIS Real-Time Polling Service Flows. 

• TSpec Bucket Depth (b) ~= DOCSIS Maximum Traffic Burst 

• TSpec Maximum Datagram Size (M) ~= <not required by DOCSIS > 

• TSpec Bucket Rate (r) ~= DOCSIS Maximum Sustained Rate and DOCSIS Minimum Reserved Traffic Rate 

• RSpec Reserved Rate (R) ~= used to calculate the Polling Interval 

• RSpec Slack Term ~= Tolerated Polling Jitter 
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This abstraction model allows standards-based RSVP implementations (as anticipated in Scenarios 2 and 3) to request 
and receive controlled load or guaranteed service from the network without necessarily requiring DOCSIS-specific info. 

In some situations, where the Application Manager and the Policy Server is acutely aware of DOCSIS, it may specify 
the Traffic Profile for the Gate using the DOCSIS Service Class Name or the DOCSIS-specific parameterization format. 

Note that there are several DOCSIS Service Flow parameters that cannot be directly resolved from the FlowSpecs; in 
these cases, the IPCablecom Multimedia specification defines defaults for those Service Flow parameters. If the 
Application Manager/Policy Server wishes to set those Service Flow parameters to something other than the defaults 
specified by the present document, the Application Manager/Policy Server shall use either the Service Class Names or 
the DOCSIS-specific parameterization formats to define the traffic profile. 

For Guaranteed Service, the Minimum Reserved Rate and the Maximum Sustained Rates are set to the same value, and 
are based on the Bucket Rate, "r". This is because Guaranteed Service provides latency guarantees, and this means a 
flow cannot be sustained at a rate greater than the rate at which the source has agreed to generate (when the reservation 
was initially made). A reservation made with a Traffic Profile specifying a Bucket Rate "r" means that the source will 
not sustain a traffic flow greater than "r". Thus, it would be incorrect to use the Reserved Rate "R" to represent any 
DOCSIS sustained rate (either minimum or maximum), in the Guaranteed service case. 

For real-time polling Scheduling however, the CMTS uses the Reserved Rate R to calculate the polling interval, so that 
traffic sources can burst at the rate of R without increasing the delay that the packets experience waiting for a DOCSIS 
upstream transmission opportunity. Although the traffic source may generate traffic at rate "R" in this case, the CMTS 
will ensure the sustained rate does not violate "r" over time. 

For Controlled Load Service, because there are no latency guarantees and because we want to enable one to use the 
DOCSIS-specific concepts of guaranteed minimum as well as maximum sustained rates, the TSpec Bucket Rate "r" is 
mapped to the DOCSIS minimum rate, and the TSpec Peak Rate "p" is mapped to the DOCSIS Maximum Sustained 
Rate. If a zero or infinite value is indicated for "r", then the DOCSIS Minimum Reserved Rate parameter shall be 
omitted. If a zero or infinite value is indicated for "p", then the DOCSIS Maximum Sustained Rate parameter shall be 
omitted. 

If a syntactic or semantic conflict exists between the DOCSIS RFI specification and the present document the DOCSIS 
RFI specification shall take precedence unless otherwise noted. 



9.3 DOCSIS Upstream Parameters 



For all of the upstream packet size calculations, the following formula must be used unless otherwise specified: The 
packet PDU shall be calculated from the first byte following the DOCSIS MAC HCS to the end of the CRC. This value 
includes the Ethernet header overhead of 18 bytes (6 bytes for source address, 6 bytes for destination address, 2 bytes 
for length, and 4 bytes for CRC). The value also incorporates DOCSIS MAC layer overhead, including the DOCSIS 
base header (6 bytes), the UGS extended header (3 bytes), and the BPIh- extended header (5 bytes). 

In the equations used in all subsequent clauses, the following variables apply: 

ENET = Ethernet overhead (1 8-bytes or 22 -bytes), a default of 1 8-bytes shall be used unless otherwise 

indicated (how the CMTS determines to use 22-bytes is outside the scope of Multimedia 
Specification). In the case of a UGS flow, packets using extended Ethernet headers that are not 
accounted for will result in the packets being dropped (packets exceeding the Grant size must be 
dropped). In the case of a RTPS flow, packets using extended Ethernet headers that are not 
accounted for will result in the packets being sent on the primary (best effort) service flow. 

DOCSIS = DOCSIS header = 6 bytes 

BPI = DOCSIS BPI header = 5 bytes 

UGS = DOCSIS UGS extended header = 3 bytes 
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9.3.1 Unsolicited Grant Sclneduling (UGS) 

Unsolicited Grant Scheduling shall be used when the Service Number is 2 (Guaranteed), the Peak Rate, Bucket Rate, 
and the Reserved Rate are all equal, and Maximum Datagram Size is equal to Minimum Policed Unit. 

The DOCSIS upstream objects shall be set as stated below. All service flow quality of service TLV encodings that are 
not defined here shall be given their default values as indicated by DOCSIS. 

The DOCSIS Unsolicited Grant Size incorporates DOCSIS MAC layer overhead in addition to the packet PDU size 
calculated using the formula specified in clause 9.3. The DOCSIS MAC layer overhead includes the DOCSIS base 
header (6 bytes), the UGS extended header (3 bytes), and optionally the BPI+ extended header (5 bytes). 

DOCSIS Unsolicited Grant Size = M + ENET + DOCSIS + UGS + BPI 

The example above assumes that BPI+ [17] is enabled. 

The DOCSIS Maximum Sustained Traffic Rate and DOCSIS Assumed Minimum Reserved Rate Packet Size 
parameters shall not be used for upstream flows. 

The DOCSIS Grants per Interval parameter shall be set to 1 . 

The DOCSIS Nominal Grant Interval parameter shall be set to the Maximum Datagram Size divided by the Reserved 
Rate converted to microseconds. 

DOCSIS Nominal Grant Interval = M/R * 1,000,000 

The DOCSIS Tolerated Grant Jitter parameter shall be set to Slack Term. The minimum allowed value is 800 |J,s. If the 
CMTS receives a Gate-Set message with a Slack term less than 800 |J,s, the CMTS shall reply with a Gate-Set-Err 
message with a IPCablecom Error-Code of "Invalid Field Value in Object". 

The DOCSIS Nominal Polling Interval parameter shall not be specified in the Traffic Profile for UGS service flows. 
The DOCSIS Tolerated Polling Jitter parameter shall not be specified in the Traffic Profile for UGS service flows. The 
DOCSIS Request/Transmission Policy parameter is a bitmask; bits 0-6 and 8 shall be set for UGS service flows. Bit 9 in 
the RequestATransmission Policy enables/disables the use of segment headers in DOCSIS 3.0 service flows. Bit 9 shall 
be set for DOCSIS 3.0 UGS service flows to disable the use of segment headers. 



9.3.2 Real-Time Polling Scheduling 



Real-Time Polling Scheduling shall be used when the Service Number is 2 (Guaranteed Service) and either the Peak 
Rate, Bucket Rate and Reserved Rate are not all equal (i.e. !(p==r==R)), or the Maximum Datagram Size is not equal to 
the Minimum Policed Unit. 

The DOCSIS upstream objects shall be set as stated below. All service flow quality of service TLV encodings that are 
not defined here shall be given their default values as indicated by DOCSIS. 

The DOCSIS Maximum Sustained Traffic Rate parameter is given in bits per second, and includes Ethernet layer 
overhead. The conversion from IP-specific parameters involves first determining the packetization rate by dividing the 
Bucket Rate by the Minimum Policed Unit. This value is then multiplied by the packet size. Minimum Policed Unit, 
including MAC layer overhead, and the entire product is scaled from bytes to bits. 

DOCSIS Maximum Sustained Traffic Rate = r/m *(m + ENET) * 8 

The DOCSIS Maximum Traffic Burst parameter shall be set to the greater of: (1) Bucket Depth including the Ethernet 
over head calculated using the Minimum Policed Unit or (2) the DOCSIS specified minimum value of 1522. 

DOCSIS Maximum Traffic Burst = max ( (Bucket Depth / m) * (m H- ENET) , 1522) 
The DOCSIS Minimum Reserved Traffic Rate parameter is the same as the DOCSIS Maximum Sustained Traffic Rate. 

DOCSIS Minimum Reserved Traffic Rate = r/m * {m + ENET) * 8 
The DOCSIS Request/Transmission Policy parameter is a bitmask; the recommended default value should be OxlF. 
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The DOCSIS Nominal Polling Interval parameter shall be set to Minimum Policed Unit divided by Reserved Rate, 
converted to microseconds. 

DOCSIS Nominal Polling Interval = m/R * 1,000,000 

The DOCSIS Tolerated Polling Jitter parameter shall be set to Slack Term. The minimum non-zero allowed value is 
800 ]ls. If the CMTS receives a Gate-Set message with a Slack Term not equal to zero and less than 800 fis, the CMTS 
shall reply with a Gate-Set-Err message with a IPCablecom Error-Code of "Invalid Field Value in Object". Upon receipt 
of a Slack Term value of the CMTS shall utilize its implementation-specific default size for this parameter, not 
microseconds. 

DOCSIS Nominal PolHng Jitter = S 

9.3.3 Best Effort Scheduling 

Best Effort Scheduling shall be used when the Service Number is 5 (Controlled-Load). 

The DOCSIS upstream objects shall be set as stated below. All service flow quality of service TLV encodings that are 
not defined here shall be given their default values as indicated by DOCSIS. 

The DOCSIS Traffic Priority shall be set to 5. 

The DOCSIS Maximum Sustained Traffic Rate parameter is given in bits per second, including Ethernet layer 
overhead. The conversion from IP-specific parameters involves first determining the packetization rate by dividing the 
Peak Rate by the Minimum Policed Unit. This value is then multiplied by the packet size. Minimum Policed Unit, 
amended to include Ethernet layer overhead, and the entire product is scaled from bytes to bits. The DOCSIS Maximum 
Sustained Traffic Rate shall be converted from the Minimum Policed Unit. 

DOCSIS Maximum Sustained Traffic Rate = p/m * (m H- ENET) * 8 

The DOCSIS Maximum Traffic Burst parameter shall be set to the greater of: (1) Bucket Depth including the Ethernet 
overhead calculated using the Minimum Policed Unit or (2) the DOCSIS specified minimum value of 1522. 

DOCSIS Maximum Traffic Burst = max ( (Bucket Depth / m) * (m H- ENET ) , 1522) 

The DOCSIS Minimum Reserved Traffic Rate parameter is calculated in a manner similar to the DOCSIS Maximum 
Sustained Traffic Rate, except that instead of using the Peak Rate parameter, the Bucket Rate is used. 

DOCSIS Minimum Reserved Traffic Rate = r/m * (m + ENET) * 8 

9.3.4 Upstream Packet Classification Encodings 
9.3.4.1 DOCSIS Upstream Packet Classification Requests 

The DOCSIS upstream classification objects shall be set as stated below. All classification TLV encodings that are not 
defined here shall be given their default values as indicated by DOCSIS. 

The DOCSIS Classifier Identifier parameter shall be used. If the Extended Classifier is used, a CMTS may choose to 
use the ClassifierlD specified by the AM, however, there are certain cases where this may not work, such as when using 
MGPI. 

The DOCSIS Service Flow Identifier parameter shall be used. 

The DOCSIS Rule Priority parameter shall be set to the Priority value specified in the classifier object. 

The DOCSIS Classification Activation State parameter shall be set as follows: 

• When the Classifier object is used, it shall be set to active (1) when the Gate utilizing the service flow is 
committed, and for all the other cases it shall be set to inactive (0). 

• When the Extended Classifier object is used, it shall be set to the value specified in the Activation State field. 
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The DOCSIS Dynamic Service Change Action shall be set as follows: 

• When the Classifier object is used, the CMTS may use the DSC Add Classifier (0), DSC Replace Classifier (1) 
and DSC Delete Classifier (2) operations per the DOCSIS RFI specification. 

• When the Extended Classifier object is used, it shall be set to the value specified in the Action field. 

The DOCSIS IP Protocol parameter shall be set to the Protocol ID value specified in the classifier object if the value is 
non-zero, and omitted otherwise. 

The DOCSIS IP Source Address parameter shall be set to the source address provided in the classifier object, so long as 
a non-zero value is provided. If the address specified in the classifier object is zero, this parameter shall be omitted. 

The DOCSIS IP Source Mask parameter shall be set as follows: 

• When the Classifier object is used, the DOCSIS IP Source Mask parameter shall be omitted. 

• When the Extended Classifier object is used, the DOCSIS IP Source Mask parameter shall be set to the same 
value as the IP Source Mask field. 

In the case of the Classifier object, the DOCSIS IP Source Port Start and DOCSIS IP Source Port End parameters shall 
be set to the same port value as the Classifier object, so long as a non-zero value is provided. If the value specified in 
the Classifier object is zero, both the DOCSIS IP Source Port Start and DOCSIS IP Source Port End parameters shall be 
omitted. 

In the case of the Extended Classifier object, the DOCSIS IP Source Port Start and DOCSIS IP Source Port End 
parameters shall be set to the corresponding source port values defined in the Extended Classifier object unless 
wildcarded ports are being used. That is, if Source Port Start = and Source Port End = 65535 in the Extended 
Classifier, these DOCSIS parameters may be omitted. 

The DOCSIS IP Destination Address parameter shall be set to the destination address provided in the classifier object, 
so long as a non-zero value is provided. If the address specified in the classifier object is zero, this parameter shall be 
omitted. 

The DOCSIS IP Destination Mask parameter shall be set as follows: 

• When the Classifier object is used, the DOCSIS IP Destination Mask parameter shall be omitted. 

• When the Extended Classifier object is used, the DOCSIS IP Destination Mask parameter shall be set to the 
same value as the IP Destination Mask field. 

In the case of the Classifier object, the DOCSIS IP Destination Port Start and DOCSIS IP Destination Port End 
parameters shall be set to the same port value as the Classifier object, so long as a non-zero value is provided. If the 
value specified in the Classifier object is zero, both the DOCSIS IP Destination Port Start and DOCSIS IP Destination 
Port End parameters shall be omitted. 

In the case of the Extended Classifier object, the DOCSIS IP Destination Port Start and DOCSIS IP Destination Port 
End parameters shall be set to the corresponding destination port values defined in the Extended Classifier object unless 
wildcarded ports are being used. That is, if Destination Port Start = and Destination Port End = 65535 in the Extended 
Classifier, these DOCSIS parameters may be omitted. 

The DOCSIS Ethernet LLC Packet Classification Encodings shall be omitted. 

The DOCSIS 802.1P/Q Packet Classification Encodings shall be omitted. 

9.4 DOCSIS Downstream Parameters 

9.4.1 Downstream QoS Encodings for Guaranteed Service 

The DOCSIS downstream service flow quality-of-service TLV encodings shall be set as stated below. All service flow 
quality of service TLV encodings that are not defined here shall be given their default values as indicated by DOCSIS. 

The downstream DOCSIS parameters are calculated using the DOCSIS MAC header from the byte following the HCS 
to the end of the CRC. This value includes the Ethernet header overhead. 
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Based on this overhead, the DOCSIS Assumed Minimum Reserved Rate Packet Size parameter shall be calculated as: 

DOCSIS Assumed Minimum Reserved Rate Packet Size = m + ENET 

The DOCSIS Maximum Sustained Traffic Rate parameter is given in bits per second, including MAC layer overhead. 
The conversion from IP-specific parameters involves first determining the packetization rate by dividing the Bucket 
Rate by the Minimum Policed Unit. This value is then multiplied by the packet size. Minimum Policed Unit, amended 
to include MAC layer overhead, and the entire product is scaled from bytes to bits. The DOCSIS Maximum Sustained 
Traffic Rate shall be calculated as: 

DOCSIS Maximum Sustained Traffic Rate = r/m * (m + ENET ) * 8 

The DOCSIS Minimum Reserved Traffic Rate is equal to the DOCSIS Maximum Sustained Traffic Rate. 

Note that the DOCSIS Maximum Sustained Traffic Rate and the DOCSIS Minimum Reserved Traffic Rate are 
calculated slightly differently in IPCablecom Multimedia and IPCablecom DQoS. IPCablecom Multimedia is based on r 
and IPCablecom DQoS is based on p. This is due to the fact that in DQoS r=p, while in Multimedia these values differ 
(in which case r is the proper rate value to use). 

For CMs which are provisioned in DOCSIS 3.0 mode, a CMTS which enforces the DOCSIS Downstream Peak Traffic 
Rate parameter shall supply the DOCSIS Downstream Peak Traffic Rate parameter. The DOCSIS Downstream Peak 
Traffic Rate parameter shall be calculated as: 

DOCSIS Downstream Peak Traffic Rate = p/m * (m + ENET ) * 8 

If the CMTS does not enforce the DOCSIS Downstream Peak Traffic Rate parameter, it shall not supply the DOCSIS 
Downstream Peak Traffic Rate parameter. 

The DOCSIS Maximum Traffic Burst parameter shall be set to the greater of: (1) Bucket Depth including the DOCSIS 
overhead calculated using the Minimum Policed Unit or (2) the DOCSIS specified minimum value of 1522. 

DOCSIS Maximum Traffic Burst = max ( (Bucket Depth / m) * (m + ENET) , 1522) 

The DOCSIS Traffic Priority parameter shall be set to 5. 

The DOCSIS Downstream Latency parameter shall be set to Slack Term, if Slack Term is non-zero. If Slack Term is 
zero, this parameter shall not be populated. 

9.4.2 Downstream QoS Encodings for Controlled Load Service 

The DOCSIS downstream service flow quality of service TLV encodings shall be set as stated below. All service flow 
quality of service TLV encodings that are not defined here shall be given their default values as indicated by DOCSIS. 

The downstream DOCSIS parameters are calculated using the DOCSIS MAC header from the byte following the HCS 
to the end of the CRC. This value includes the Ethernet header overhead. 

Based on this overhead, the DOCSIS Assumed Minimum Reserved Rate Packet Size parameter shall be calculated as: 

DOCSIS Assumed Minimum Reserved Rate Packet Size = m + ENET 

The DOCSIS Maximum Sustained Traffic Rate parameter is given in bits per second, including MAC layer overhead. 
The conversion from IP-specific parameters involves first determining the packetization rate by dividing the Peak Rate 
by the Minimum Policed Unit. This value is then multiplied by the packet size. Minimum Policed Unit, amended to 
include MAC layer overhead, and the entire product is scaled from bytes to bits. The DOCSIS Maximum Sustained 
Traffic Rate shall be calculated as: 

DOCSIS Maximum Sustained Traffic Rate = p/m *(m + ENET) * 8 

For CMs which are provisioned in DOCSIS 3.0 mode, a CMTS which enforces the DOCSIS Downstream Peak Traffic 
Rate parameter shall supply the DOCSIS Downstream Peak Traffic Rate parameter. The DOCSIS Downstream Peak 
Traffic Rate parameter is equal to the DOCSIS Maximum Sustained Traffic Rate. 

If the CMTS does not enforce the DOCSIS Downstream Peak Traffic Rate parameter, it shall not supply the DOCSIS 
Downstream Peak Traffic Rate parameter. 
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The DOCSIS Minimum Reserved Traffic Rate parameter is calculated in a manner similar to the DOCSIS Maximum 
Sustained Traffic Rate, except that instead of using the Peak Rate, the Bucket Rate is used. 

DOCSIS Minimum Reserved Traffic Rate= r/m * (m + ENET) * 8 

The DOCSIS Maximum Traffic Burst parameter shall be set to the greater of: (1) Bucket Depth including the DOCSIS 
overhead calculated using the Maximum Datagram Size or (2) the DOCSIS specified minimum value of 1522. 

DOCSIS Maximum Traffic Burst = max ((Bucket Depth / M) * (M + ENET) , 1522) 

The DOCSIS Traffic Priority parameter shall be set to 5. 

The DOCSIS Downstream Latency parameter shall not be populated. 

9.4.3 Downstream Packet Classification Encodings 
9.4.3.1 DOCSIS Downstream Packet Classification Requests 

The DOCSIS downstream classification objects shall be set as stated below. All classification TLV encodings that are 
not defined here shall be given their default values as indicated by DOCSIS. 

The DOCSIS Classifier Identifier parameter shall be used. If the Extended Classifier is used, a CMTS may choose to 
use the ClassifierlD specified by the AM, however, there are certain cases where this may not work, such as when using 
MGPI. 

The DOCSIS Service Flow Identifier parameter shall be used. 

The DOCSIS Rule Priority parameter shall be set to the Priority value specified in the classifier object. 

The DOCSIS Classification Activation State parameter shall be set as follows: 

• When the Classifier object is used, it shall be set to active (1) when the Gate utilizing the service flow is 
committed, and for all the other cases it shall be set to inactive (0). 

• When the Extended Classifier object is used, it shall be set to the value specified in the Activation State field. 
The DOCSIS Dynamic Service Change Action shall be set as follows: 

• When the Classifier object is used, the CMTS may use the DSC Add Classifier (0), DSC Replace Classifier (I) 
and DSC Delete Classifier (2) operations per the DOCSIS RFI specification. 

• When the Extended Classifier object is used, it shall be set to the value specified in the Action field. 

The DOCSIS IP Protocol parameter shall be set to the Protocol ID value specified in the classifier object if the value is 
non-zero, and omitted otherwise. 

The DOCSIS IP Source Address parameter shall be set to the source address provided in the classifier object, so long as 
a non-zero value is provided. If the address specified in the classifier object is zero, this parameter shall be omitted. 

The DOCSIS IP Source Mask parameter shall be set as follows: 

• When the Classifier object is used, the DOCSIS IP Source Mask parameter shall be omitted. 

• When the Extended Classifier object is used, the DOCSIS IP Source Mask parameter shall be set to the same 
value as the IP Source Mask field. 

In the case of the Classifier object, the DOCSIS IP Source Port Start and DOCSIS IP Source Port End parameters shall 
be set to the same port value as the Classifier object, so long as a non-zero value is provided. If the value specified in 
the Classifier object is zero, both the DOCSIS IP Source Port Start and DOCSIS IP Source Port End parameters shall be 
omitted. 

In the case of the Extended Classifier object, the DOCSIS IP Source Port Start and DOCSIS IP Source Port End 
parameters shall be set to the corresponding source port values defined in the Extended Classifier object unless 
wildcarded ports are being used. That is, if Source Port Start = and Source Port End = 65535 in the Extended 
Classifier, these DOCSIS parameters may be omitted. 
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The DOCSIS IP Destination Address parameter shall be set to the destination address provided in the classifier object, 
so long as a non-zero value is provided. If the address specified in the classifier object is zero, this parameter shall be 
omitted. 

The DOCSIS IP Destination Mask parameter shall be set as follows: 

• When the Classifier object is used, the DOCSIS IP Destination Mask parameter shall be omitted. 

• When the Extended Classifier object is used, the DOCSIS IP Destination Mask parameter shall be set to the 
same value as the IP Destination Mask field. 

In the case of the Classifier object, the DOCSIS IP Destination Port Start and DOCSIS IP Destination Port End 
parameters shall be set to the same port value as the Classifier object, so long as a non-zero value is provided. If the 
value specified in the Classifier object is zero, both the DOCSIS IP Destination Port Start and DOCSIS IP Destination 
Port End parameters shall be omitted. 

In the case of the Extended Classifier object, the DOCSIS IP Destination Port Start and DOCSIS IP Destination Port 
End parameters shall be set to the corresponding destination port values defined in the Extended Classifier object unless 
wildcarded ports are being used. That is if Destination Port Start = and Destination Port End = 65535 in the Extended 
Classifier, these DOCSIS parameters may be omitted. 

The DOCSIS Ethernet LLC Packet Classification Encodings shall be omitted. 

The DOCSIS 802.1P/Q Packet Classification Encodings shall be omitted. 



1 Message Flows 



This clause provides two interaction scenarios between the various network elements previously introduced in the 
present document. The first interaction outlines at a relatively high-level the basic message exchanges that take place 
within the IPCablecom Multimedia framework in order to authorize, reserve and commit access network resources 
under Scenario 1 . The second interaction provides a very detailed breakout of each message and attribute involved in 
the IPCablecom Multimedia QoS and EM interfaces. 



10.1 Basic Message Sequence 



Client 


1 
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CM 


5 


4 
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Application Manager 
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1 


♦ 


Application Manager 
1 


2 






CMTS 


6 
3 



♦ 


►♦ 


1 


Policy 

Server 

'm' 


1 


Policy 

Server 

1 


y 



2. 



Figure 8: Basic lUlessage Sequence 

Client issues a session setup request to the Application Manager via Application Layer signalling. The client 
may authenticate itself to the Application Manager during this step. 

Before the Application Manager activates the session, the Application Manager issues a Gate Set (in a COPS 
DECISION message) and sends it to Policy Server in order to determine if the session setup request should be 
allowed to proceed. Message includes: 

a. AMID 
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b. SubscriberlD 

c. Trans actionID 

d. Classifier 

e. Traffic Profile for Flow 

f. Gate-Spec 

3. Upon receiving the request, the Policy Server checks the request against the policy rules and if the request is 
approved, sends a Gate-Set to the CMTS. Message includes: 

a. AMID 

b. SubscriberlD 

c. TransactionID 

d. Classifier 

e. Traffic Profile for Flow (Authorized, Reserved and Committed) 

f. Gate-Spec 

4. If the flow is unshared or if the flow is shared but not yet created, the CMTS uses the classifier and Traffic 
Profile information to trigger the activation of the flow by issuing the appropriate DOCSIS messages. 

5. CM acknowledges with the appropriate DOCSIS messaging. 

6. CMTS issues a Gate-Set-Ack to the Policy Server in response to the Gate-Set message received in Step 3. 
Message includes: 

a. AMID 

b. TransactionID 

c. GatelD 

d. SubscriberlD 

e. SharedResourcelD (if a shared resource is used to fulfil the resource commitment) 

7. In response the Policy Server will generate a Gate-Set-Ack to the AM; this tells the AM that the Policy 
Request has been admitted and the client's request can proceed, and the necessary resources in the underlying 
network have been reserved. Message includes: 

a. AMID 

b. TransactionID 

c. GatelD 

d. SubscriberlD 

e. SharedResourcelD (if a shared resource is used to fulfil the resource commitment) 

8. Application Manager, upon receiving the Gate-Set-Ack will inform the client that the session establishment 
can proceed. 
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10.2 Detailed Message Sequence 



Client 



CM 



CMTS 



PS 



RKS 



AM 



(1) Application Signaling 




Session in Progress 

n 
(10) Application Signaling 



(13) DSD-REQ, 

(14) DSD-Rsp 



(12) Gate-Delete 



(11) Gate-Delete 



il5a)^Gafe-Del-Ack 

(15b)QoS_Release 
(1 6a) QoS^Release Ack 



(16b)Gafe-Del-Ack 
i16c)^olicK_De)ete 
(17)Policy_DeleteAck 



Figure 9: Detailed IVIessage Sequence 

The pages that follow describe in detail the messages that are being exchanged in an example IPCablecom Multimedia 
session. The bandwidth numbers are purely examples, and do not correlate to any particular service. Only the upstream 
access network resources are being reserved and committed for clarity. Also, BPI related TLVs have been left out of the 
DOCSIS messages for clarity. 

1 . The client initializes the session by querying an Application Manager for the necessary resources to use the 
application. An example of this would be a software based video game, asking for resources to play an online 
game. This signalling is out of scope for the present document. 

2. After receiving the application signalling from the client, the Application Manager issues a Gate-Set to the 
Policy Server, requesting the needed resources for this session. 
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12 3 


COPS Header 


Version 
0x1 


Flags 
0x0 


Op-Code 
0x02 


Client-Type 
0x800A 


Message Length 
0x00000088 


COPS Handle Object 


Length 
0x0008 


C-Num 
0x01 


C-Type 
0x01 


Handle 
0x00001234 


COPS Context Object 


Length 
0x0008 


C-Num 
0x02 


C-Type 
0x01 


Request Type (R-Type) 
0x0008 (Configuration Request) 


Message Type (M-Type) 
0x0000 


COPS Decision Flags Object 


Length 
0x0008 


C-Num 
0x06 


C-Type 
0x01 


Command Code 

0x0001 (Install Configuration) 


Flags 
0x0000 


COPS Decision Client Specific Decision Data Object Header 


Length 
OxOOAO 


C-Num 
0x06 


C-Type 
0x04 


Multimedia TransactionID Object 


Length 
0x0008 


S-Num 
0x01 


S-Type 
0x01 


TransactionID 
0x9999 


Gate Command 
0x0004 (Gate-Set) 


Multimedia AMID Object 


Length 
0x0008 


S-Num 
0x02 


S-Type 
0x01 


Application TypeOxOOOO 


Application Manager Tag 
0x5678 


Multimedia SubscriberlD Object 


Length 
0x0008 


S-Num 
0x03 


S-Type 
0x01 


SubscriberlD 
0x01010101 


Multimedia GateSpec Object 


Length 
0x0010 


S-Num 
0x05 


S-Type 
0x01 


Flags 
0x01 


DSCP/TOS Field 
0x00 


DSCP/TOS Mask 
0x00 


SessionClassID 
0x00 


Timer T1 

0x00C8 (200 seconds) 


Timer T2 

0x01 20 (300 seconds) 


Timer T3 

0x003C (60 seconds) 


Timer T4 

0x001 E (30 seconds) 


Multimedia FlowSpec Object 


Length 
0x0024 


S-Num 
0x07 


S-Type 
0x01 


Envelope 
0x07 


Service Number 
0x02 


Reserved 


Reserved 


Combined Authorized, Reserved and Committed Envelopes 


Token Bucket Rate [r] (encoded as IEEE floating point) 
0x46104000 (10,000 Bps) 


Token Bucket Size [b] (encoded as IEEE floating point) 
0x43480000 (200 bytes) 


Peak Data Rate [p] (encoded as IEEE floating point) 
0x46104000 (10,000 Bps) 


Minimum Policed Unit [m] 
0x00000008 (200 bytes) 


Maximum Packet Size [M] 
0x00000008 (200 bytes) 


Rate [R] (encoded as IEEE floating point) 
0x46104000 (10,000 Bps) 
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1 2 


3 


Slack Term [S] 
0x00000320 (800 ^is) 


IVIultimedia Classifier Object 


Length 
0x0018 


S-Num 
0x06 


S-Type 
0x01 


Reserved 


ProtocollD 
0x11 (17UDP) 


DSCP/TOS Field 
0x00 


DSCP/TOS Mask 
0x00 


Source IP Address 
0x01010101 


Destination IP Address 
0x02020202 


Source Port 
0x1 234 


Destination Port 
0x9876 


Priority 
0x0040 (64) 


Reserved 



After the PS receives the Gate-Set from the Application Manager, it checks to see if the request is authorized, 
and if so, sends a Gate-Set to the CMTS. 



|1 |2 


3 


COPS Header 


Version 
0x1 


Flags 
0x0 


Op-Code 
0x02 


Client-Type 
0x800A 


Message Length 
0x00000064 


COPS Handle Object 


Length 
0x0008 


C-Num 
0x01 


C-Type 
0x01 


Handle 
0x00005678 


COPS Context Object 


Length 
0x0008 


C-Num 
0x02 


C-Type 
0x01 


Request Type (R-Type) 
0x0008 (Configuration Request) 


Message Type (M-Type) 
0x0000 


COPS Decision Flags Object 


Length 
0x0008 


C-Num 
0x06 


C-Type 
0x01 


Command Code 

0x0001 (Install Configuration) 


Flags 
0x0000 


COPS Decision Client Specific Decision Data Object Header 


Length 
OxOOCC 


C-Num 
0x06 


C-Type 
0x04 


Multimedia TransactionID Object 


Length 
0x0008 


S-Num 
0x01 


S-Type 
0x01 


TransactionID 
0x0001 


Gate Command 
0x0004 (Gate-Set) 


Multimedia AMID Object 


Length 
0x0008 


S-Num 
0x02 


S-Type 
0x01 


AMID 
0x0000 


Application Manager Tag 
0x5678 


Multimedia SubscriberlD Object 


Length 
0x0008 


S-Num 
0x03 


S-Type 
0x01 


SubscriberlD 
0x01010101 


Multimedia GateSpec Object 


Length 
0x0010 


S-Num 
0x05 


S-Type 
0x01 


Direction 
0x01 


DSCP/TOS Field 
0x00 


DSCP/TOS Mask 
0x00 


SessionClassID 
0x00 
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1 


2 


3 


Timer T1 

OxOOCS (200 seconds) 


Timer T2 
0x012C(300seconds) 


Timer T3 

0x003C (60 seconds) 


Timer T4 

0x001 E (30 seconds) 


IVIultimedia FlowSpec Object 


Length 
0x0024 


S-Num 
0x07 


S-Type 
0x01 


Envelope 
0x07 


Service Number 
0x02 


Reserved 


Reserved 


Combined Authorized, Reserved, and Committed Envelopes 


Token Bucket Rate [r] (encoded as IEEE floating point) 
0x461 C4000 (10,000 Bps) 


Token Bucket Size [b] (encoded as IEEE floating point) 
0x43480000 (200 Bytes) 


Peak Data Rate [p] (encoded as IEEE floating point) 
0X461C4000 (10,000 Bytes) 


Minimum Policed Unit [m] 
OxOOOOOOCS (200 Bytes) 


Maximum Packet Size [M] 
OxOOOOOOCS (200 Bytes) 


Rate [R] (encoded as IEEE floating point) 
0X461C4000 (10,000 Bytes) 


Slack Term [S] 
0x00000320 (800 i^s) 


Multimedia Classifier Object 


Length 
0x0018 


S-Num 
0x06 


S-Type 
0x01 


Reserved 


ProtocollD 
0x11 


DSCP/TOS Field 
0x00 


DSCP/TOS Mask 
0x00 


Source IP Address 
0x01010101 


Destination IP Address 
0x02020202 


Source Port 
0x1234 


Destination Port 
0x9876 


Priority 
0x0040 (64) 


Reserved 


Multimedia Event Generation Info Object 


Length 
0x002C 


S-Num 
0x08 


S-Type 
0x01 


Primary RKS Address 
0x03030303 


Primary RKS Port 
0x1 1 1 1 


Reserved 


Secondary RKS Address 
0x04040404 


Secondary RKS Port 
0x1 1 1 1 


Reserved 


BCID 

0x3e481 208202020202031 3436302d3035303030300003db77 













4. If CMTS admission control succeeds, the CMTS will initiate reserving and committing the access network 
resources by issuing a DSA to the Cable Modem. 
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12 3 


MAC Management Header 










Transaction ID 
0x0007 


US Service Flow 
0x18 


Length 
0x29 


Service Flow ID 
0x02 


Length 
0x04 


Value 
0x0000 


Value (cont.) 
0001 


Service ID 
0x03 


Length 
0x02 


Value 
0x0001 


QoS Param Set 
0x06 


Length 
0x01 


Value 

0x06 (Ad.+Act.) 


Scheduling Type 
OxOF 


Length 
0x01 


Value 
0x06 


UGS Size 
0x13 


Length 
0x02 


Value 

0x00E8 (232 Bytes) 


Nom. Grant Int. 
0x14 


Length 
0x04 


Value 
0x0000 


Value (cont.) 
4E20 (20,000 us) 


Grants Per Interval 
0x16 


Length 
0x01 


Value 
0x01 


RX/TX Policy 
0x10 


Length 
0x04 


Value 
0x00 


Value (cont.) 
00037F 


Tol. Grant Jitter 
0x15 


Length 
0x04 


Value 
0x000003 


Value (cont.) 
20 (800 us) 


US Pkt. GIfr. 
0x16 


Length 
0x0x2 B 


Clfr. ID 
0x02 


Length 
0x02 


Value 
0x0001 


Service Flow ID 
0x04 


Length 
0x04 


Value 
0x000000 


Value (cont.) 
01 


Rule Priority 
0x05 


Length 
0x01 


Value 
0x40 


GIfr Act. State 
0x06 


Length 
0x01 


Value 

0x01 (Active) 


IP Pkt. Clfr. 0x09 


Length 
0x001 A 


IP Protocol 
0x02 


Length 
0x02 


Value 
0x00 


Value (cont.) 
11 (17UDP) 


IP Src. Addr 
0x03 


Length 
0x04 


Value 
0x01 


Value (cont.) 
010101 


IP Src Port Start 
0x07 


Length 
0x02 


Value 
0x1234 


IP Src Port End 
0x08 


Length 
0x02 


Value 
0x1234 


IP Dest Port Start 
0x09 


Length 
0x02 


Value 
0x9876 


IP Dest Port End 
OxOA 






Length 
0x02 


Value 
0x9876 





5. The CM responds to the CMTS with a DSA-RSP. 

n [2 



Mac Management Header 



TransactionID 
0x0007 



Confirm. Code 
0x00 
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6a. The CMTS completes the transaction with a DSA-ACK. 

|1 |2 |3~ 

lyiaciyianagement Header 



TransactionID 
0x0007 



Confirm. Code 
0x00 



6b. Once a DSA-RSP is received by the CMTS from the CM confirming a successful transaction, the CMTS will 
send a Gate-Set- Ack to the Policy Server. 






1 |2 


3 


COPS Header 


Version 
0x1 


Flags 
0x1 


Op-Code 
0x03 


Client-Type 
0x800A 


IVIessage Length 
OxOOOOOOSC 


COPS Handle Object 


Length 
0x0008 


C-Num 
0x01 


C-Type 
0x01 


Handle 
0x00005678 


COPS Report-Type Object 


Length 
0x0008 


C-Num 
0x12 


C-Type 
0x01 


Report Type (R-Type) 
0x0001 (Success) 


Reserved 


COPS ClientSI Object Header 


Length 
0x0024 


C-Num 
0x09 


C-Type 
0x01 


IVIultimedia TransactionID Object 


Length 
0x0008 


S-Num 
0x01 


S-Type 
0x01 


TransactionID 
0x0001 


Gate Command 
0x0005 (Gate-Set-Ack) 


Multimedia AIVIID Object 


Length 
0x0008 


S-Num 
0x02 


S-Type 
0x01 


AMID 
0x0000 


Application Manager Tag 
0x5678 


Multimedia SubscriberlD Object 


Length 
0x0008 


S-Num 
0x03 


S-Type 
0x01 


SubscriberlD 
0x01010101 


Multimedia GatelD Object 


Length 
0x0008 


S-Num 
0x04 


S-Type 
0x01 


GatelD 

0x1 2345678 



6c. The CMTS will also send a QoS_Reserve Event message to signal to the RKS that the access network 
resources have been reserved. 
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1 



Accqunting-Reguest _R3dj_us Header 



Radius Ven. 
0x1 A 



Spec. 



Length 
0x54 



Vendor ID 
0x0000 



Vendor ID (cont. 
11 8B 



Type 
0x01 



EM Header) 



Length 
Ox4E 



Version 
0x0003 



BCID 
0x3048 



BCID (cont.) 

1 208202020202031 3436302D3035303030300003DB77 



Event IVIessage Type 
0x0007 (QoS-Reserver) 



Element Type 
0x0002 (CMTS) 



Element ID 
0x2020202031323334 



Time Zone 
0X302D303530303030 



Sequence Number 
0x0000 



Sequence Number (cont.' 
0001 



Event Time 
0x3230 



Event Time (cont.) 
3033313230363030303030302E303030 



Status 
0x00000000 



Priority 
0x80(128) 



Attribute Count 
0x0004 



Event Object 
0x00 



Radius Ven. 
0x1 A 



Spec. 



Length 
0x5C 



Vendor ID 
0x0000 



Vendor ID (cont.) 
118B 



Type 
0x20 



Length 
0x56 



QoS_Descriptor 

.QxP0QQ_207p IQoS Status BJtrnask - _1_0000001 1 1_1_1 OIJ 

QoS_Descriptor (cont.) 

.QQ_Q.QQP_QQ .(.Service Class N_arTieJ 



QoS_Descriptor (cont.^ 
.QQ_Q.QQP_QO_(.Seryice Class _NarTie cqrit.J 
QoS_Descriptor (cont.) 
.QQ_Q.QQP_QO_(.Seryice Cla_ss Narrie cqrit.J 



QoS_Descriptor (cont.^ 
.QQ_Q.QQP_QO_(.Seryice Class _N_arTie cqrit.J 
QoS_Descriptor (cont.) 
.QQP_QQP_Q6_CSeryice Flow Scheduling Type ■ 



UGS). 



QoS_Descriptor (cont.) 

.QPP_Q4e2PlNqrininal Grant InteryaJ _-_20p00jis) 

QoS_Descriptor (cont.) 

00000320 (Tqlerated Grant J itter :_800jjs) 



-1) 



QoS_Descriptor (cont.) 

.QPP_QPP_Q1 IGraJlls P_?[ Jptej-yaJ 

QoS_Descriptor (cont.) 

.QPP_QPPe8_(.y nsqijcited Grant Size - 232 b^tes) 



QoS_Descriptor (cont.^ 

0000037F (Request Transmission Policy -1101111111) 



Radius Ven. 
0x1 A 



Spec. 



Length 
OxOC 



Vendor ID 
0x0000 



£75/ 



121 



ETSI TS 102 879 VI .1.1 (2010-06) 






1 


2 


3 


Vendor ID (cont.) 
11 SB 


Type 
0x1 E 


Length 
0x06 


SF ID 
0x00000001 


Radius Ven. Spec. 
0x1 A 


Length 
OxOA 


Vendor ID 
0x0000 


Vendor ID (cont.) 
11 SB 


Type 
0x32 


Length 
0x04 


Flow Direction 
0x0001 (Upstream) 


Radius Ven. Spec. 
0x1 A 


Length 
OxOA 


Vendor ID 
0x00001186 


Type 
0x37 


Length 
0x04 


Element_Requesting_QoS 
0x0001 (Policy Server) 



6d. Immediately after sending the QoS_Reserve Event Message to the RKS, the CMTS will send the 

QoS_Commit Event Message to the RKS. This is due to the fact that the access network resources are being 
reserved and committed in one step. 







1 



Accouriting-Request Radius Header 



Radius Ven. 
0x1 A 



Spec. 



Length 
0x54 



Vendor ID 
0x0000 



Vendor ID (cont.) 
118B 



Type 
0x01 



EM Header) 



Length 
0x4E 



Version 
0x0003 



BCID 
0x3E48 



BCID (cont.) 

1 208202020202031 3436302D3035303030300003DB77 



Event Message Type 
0x0013 (QoS-Commit) 



Element Type 
0x0002 (CMTS) 



Element ID 
0x2020202031 323334 



Time Zone 
0x302d303530303030 







Sequence Number 
0x0000 




Sequence Number (cont.) 
0002 


Event Time 
0x3230 


Event Time (cont.) 

303331 3230363030303030302E303030 








Status 
0x00000000 


Priority 
0x80(128) 


Attribute Count 
0x0003 


Event Object 
0x00 


Radius Ven. Spec. 
0x1 A 


Length 
0x5C 


Vendor ID 
0x0000 


Vendor ID (cont.) 
118B 


Type 
0x20 


Length 
0x56 



£75/ 



122 



ETSI TS 102 879 VI .1.1 (2010-06) 



1 2 


3 1 


QoS Descriptor 

0X0000207D (QoS Status BItmask - 1 0000001 111101] 


QoS_Descriptor (cont.) 
00000000 (Service Class Name) 


QoS_Descrlptor (cont.) 

00000000 (Service Class Name cont.) 


QoS_Descrlptor (cont.) 

00000000 (Service Class Name cont.) 


QoS_Descrlptor (cont.) 

00000000 (Service Class Name cont.) 


QoS_Descrlptor (cont.) 

00000006 (Service Flow Scheduling Type - UGS) 


QoS_Descrlptor (cont.) 

00004e20 (Nominal Grant Interval - 20000ps) 


QoS Descriptor (cont.) 

00000320 (Tolerated Grant Jitter - SOOi^s) 


QoS Descriptor (cont.) 
00000001 (Grants Per Interval -1] 


QoS_Descrlptor (cont.) 

OOOOOOeS (Unsolicited Grant Size - 232 bytesj 


QoS_Descrlptor (cont.) 

0000037F (Request Transmission Policy -1101111111) 


Radius Ven. Spec. 
0x1 A 


Length 
OxOC 


Vendor ID 
0x0000 


Vendor ID (cont.) 
118B 


Type 
0x1 E 


Length 
0x06 


SF ID 
0x00000001 


Radius Ven. Spec. 
0x1 A 


Length 
OxOA 


Vendor ID 
0x0000 


Vendor ID (cont.) 
118B 


Type 
0x32 


Length 
0x04 






Flow Direction 
0x0001 (Upstream) 





7a. After receiving and recording the QoS_Reserve Event Message, the RKS acknowledges the message. 

|1 |2 |3 

Accpuntjng-Response Radius Header 



7b. After receiving and recording the QoS_Commit Event Message, the RKS acknowledges the message. 







1 



AQCou ntj ng- Response Rad I us _Header 



7c. As a result of receiving a Gate-Set- Ack from the CMTS, the Policy Server will send a Gate-Set-ck to the 
Application Manager to complete the transaction. 
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|1 |2 


3 


COPS Header 


Version 
0x1 


Flags 
0x1 


Op-Code 
0x03 


Client-Type 
OxBOOA 


IVIessage Length 
OxOOOOOOSC 


COPS Handle Object 


Length 
0x0008 


C-Num 
0x01 


C-Type 
0x01 


Handle 
0x00001234 


COPS Report-Type Object 


Length 
0x0008 


C-Num 
0x12 


C-Type 
0x01 


Report Type (R-Type) 
0x0001 (Success) 


Reserved 


COPS ClientSI Object Header 


Length 
0x0024 


C-Num 
0x09 


C-Type 
0x01 


Multimedia TransactionID Object 


Length 
0x0008 


S-Num 
0x01 


S-Type 
0x01 


TransactionID 
0x9999 


Gate Command 
0x0005 


Multimedia AMID Object 


Length 
0x0008 


S-Num 
0x02 


S-Type 
0x01 


AMID 
0x0000 


Application Manager Tag 
0x5678 


Multimedia SubscriberlD Object 


Length 
0x0008 


S-Num 
0x03 


S-Type 
0x01 


SubscriberlD 
0x01010101 


Multimedia GatelD Object 


Length 
0x0008 


S-Num 
0x04 


S-Type 
0x01 


GatelD 

0x1 2345678 



7d. The Policy Server will also send a Policy_Request Event Message to the RKS to track the Policy Request and 
associated outcome. 



|1 


2 |3 


Accounting-Request Radius Header 








Radius Ven. Spec. 
0x1 A 


Length 
0x54 


Vendor ID 
0x0000 


Vendor ID (cent.) 
118B 


Type (EM Header) 
0x01 


Length 
Ox4E 


Version 
0x0001 


BCID 
0x3 E48 


BCID (cont.) 

1 208202020202031 3436302D3035303030300003DB77 












Event Message Type 
0x0015 (Policy_Request) 
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2 
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Element Type 
0x0004 (Policy Server) 


Element ID 
0x2020202035363738 






Time Zone 
0X302E303530303030 






Sequence Number 
0x0000 


Sequence Number (cent.) 
0001 


Event Time 
0x3230 


Event Time (cont.) 

303331 3230363030303030302E3231 30 








Status 
0x00000000 


Priority 
0x80(128) 


Attribute Count 
0x0004 


Event Object 
0x00 


Radius Ven. Spec. 
0x1 A 


Length 
OxOC 


Vendor ID 
0x0000 


Vendor ID (cont.) 
118B 


Type 
0x3 D 


Length 
0x06 


Application Manager ID 
0x00005678 


Radius Ven. Spec. 
0x1 A 


Length 
OxOC 


Vendor ID 
0x0000 


Vendor ID (cont.) 
118B 


Type 
0x34 


Length 
0x06 


Subscriber ID 
0x01010101 


Radius Ven. Spec. 
0x1 A 


Length 
OxOA 


Vendor ID 
0x0000 


Vendor ID (cont.) 
118B 


Type 
0x3C 


Length 
0x04 


Policy_Decision_Status 
0x0001 (Policy Approved) 


Radius Ven. Spec. 
0x1 A 


Length 
0x1 C 


Vendor ID 
0x00001188 


Type 
0x31 


Length 
0x16 


FEID 
0x0000 


FEID (cont.) 

000000000000005061 636B65744361 626C65 









8. After receiving and recording the Policy_Request Event Message, the RKS acknowledges the message. 







1 



AccountJ PS"_'?6sponse Rad i us _Header 



9. The AppHcation Manger will reply to the client to inform the client that it can now play the game. This 
signalling is out of scope for the present document. 

10. When the client is finished with the application, it will notify the Application Manager. This signalling is out 
of scope for the present document. 
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1 1 . The Application Manager will terminate the session by sending a Gate-Delete to the Policy Server. 



|1 |2 


3 


COPS Header 


Version 
0x1 


Flags 
0x0 


Op-Code 
0x02 


Client-Type 
0x800A 


Message Length 
0x00000044 


COPS Handle Object 


Length 
0x0008 


C-Num 
0x01 


C-Type 
0x01 


Handle 
0x00001234 


COPS Context Object 


Length 
0x0008 


C-Num 
0x02 


C-Type 
0x01 


Request Type (R-Type) 
0x0008 (Configuration Request) 


Message Type (M-Type) 
0x0000 


COPS Decision Flags Object 


Length 
0x0008 


C-Num 
0x06 


C-Type 
0x01 


Command Code 

0x0001 (Install Configuration) 


Flags 
0x0000 


COPS Decision Client Specific Decision Data Object Header 


Length 
0x0014 


C-Num 
0x06 


C-Type 
0x04 


Multimedia TransactionID Object 


Length 
0x0008 


S-Num 
0x01 


S-Type 
0x01 


TransactionID 
0x9998 


Gate Command 
OxOOOA (Gate-Delete) 


Multimedia AMID Object 


Length 
0x0008 


S-Num 
0x02 


S-Type 
0x01 


AMID 
0x0000 


Application Manager Tag 
0x5678 


Multimedia SubscriberlD Object 


Length 
0x0008 


S-Num 
0x03 


S-Type 
0x01 


SubscriberlD 
0x01010101 


Multimedia GatelD Object 


Length 
0x0008 


S-Num 
0x04 


S-Type 
0x01 


GatelD 

0x1 2345678 
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12. IThe Policy Server will instruct the CMTS to tear down the session by sending a Gate-Delete. 






1 |2 


3 


COPS Header 


Version 
0x1 


Flags 
0x0 


Op-Code 
0x02 


Client-Type 
0x800A 


Message Length 
0x00000044 


COPS Handle Object 


Length 
0x0008 


C-Num 
0x01 


C-Type 
0x01 


Handle 
0x00005678 


COPS Context Object 


Length 
0x0008 


C-Num 
0x02 


C-Type 
0x01 


Request Type (R-Type) 
0x0008 (Configuration Request) 


Message Type (M-Type) 
0x0000 


COPS Decision Flags Object 


Length 
0x0008 


C-Num 
0x06 


C-Type 
0x01 


Command Code 

0x0001 (Install Configuration) 


Flags 
0x0000 


COPS Decision Client Specific Decision Data Object Header 


Length 
0x0014 


C-Num 
0x09 


C-Type 
0x01 


Multimedia TransactionID Object 


Length 
0x0008 


S-Num 
0x01 


S-Type 
0x01 


TransactionID 
0x0002 


Gate Command 
OxOOOA (Gate-Delete) 


Multimedia AMID Object 


Length 
0x0008 


S-Num 
0x02 


S-Type 
0x01 


AMID 
0x0000 


Application Manager Tag 
0x5678 


Multimedia SubscriberlD Object 


Length 
0x0008 


S-Num 
0x03 


S-Type 
0x01 


SubscriberlD 
0x01010101 


Multimedia GatelD Object 


Length 
0x0008 


S-Num 
0x04 


S-Type 
0x01 



GatelD 
0x12345678 



13. The CMTS will tear down the access network resources by sending a DSD-REQ to the CM. 



[1 

MAC Management Header 



TransactionID 
0x0008 



Reserved 



SFID 
0x00000001 
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14. The CM will acknowledge the session deletion with a DSD-RSP. 



1 



MAC Management Header 



TransactionID 
0x0008 



Confirm. Code 
0x00 



Reserved 



15a. The CMTS will complete the Gate-Control transaction with a Gate-Delete-Ack. 



|1 |2 


3 


COPS Header 


Version 
0x1 


Flags 
0x1 


Op-Code 
0x03 


Client-Type 
0x800A 


Message Length 
0x00000034 


COPS Handle Object 


Length 
0x0008 


C-Num 
0x01 


C-Type 
0x01 


Handle 
0x00005678 


COPS Report Ty 


pe Object 


Length 
0x0008 


C-Num 
0x12 


C-Type 
0x01 


Report Type (R-Iype) 
0x0001 


Reserved 


COPS ClientSI Object Header 


Length 
0x001 C 


C-Num 
0x09 


C-Type 
0x01 


Multimedia TransactionID Object 


Length 
0x0008 


S-Num 
0x01 


S-Type 
0x01 


TransactionID 
0x0002 


Gate Command 

OxOOOB (Gate-Delete-Ack) 


Multimedia AMID Object 


Length 

0x0008 ( 


3-Num 
Dx02 


S-Type 
0x01 


AMID / 
0x0000 ( 


Application Manager Tag 
Dx5678 


Multimedia GatelD Object 


Length 
0x0008 


S-Num 
0x04 


S-Type 
0x01 


GatelD 
0x12345678 



15b. Also upon the receipt of the DSD-RSP, the CMTS will inform the RKS that the network access resources have 
been freed by sending a QoS_Release. 
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1 


2 


3 1 


Accounting-Request Radius Header 








Radius Ven. Spec. 
0x1 A 


Length 
0x54 


Vendor ID 
0x0000 


Vendor ID (cent.) 
118B 


Type (EM Header) 
0x01 


Length 
0x4 E 


Version 
0x0001 


BCID 
0x3E48 


BCID (cent.) 

1 208202020202031 3436302D3035303030300003DB77 












Event IVlessage Type 
0x0008 (QoS Release) 


Element Type 
0x0002 (CMTS) 


Element ID 
0x2020202031 323334 






Time Zone 
0x3020303530303030 


1 




Sequence Number 
0x0000 


Sequence Number (cent.) 
0003 


Event Time 
0x3230 


Event Time (cent.) 
3032313230363030303030302E333030 








Status 
0x00000000 


Priority 
0x80(128) 


Attribute Count 
0x0005 


Event Object 
0x00 


Radius Ven. Spec. 
0x1 A 


Length 
OxOC 


Vendor ID 
0x0000 


Vendor ID (cent.) 
118B 


Type 
0x1 E 


Length 
0x06 


SF ID 
0x00000001 


Radius Ven. Spec. 
0x1 A 


Length 
OxOA 


Vendor ID 
0x0000 


Vendor ID (cent.) 
118B 


Type 
0x32 


Length 
0x04 


Flow_Direction 
0x0001 (Upstream) 


Radius Ven. Spec. 
0x1 A 


Length 
OxOA 


Vendor ID 
0x00001 18B 


Type 
0x38 


Length 
0x04 


QoS Release Reason 
0x0001 (Gate Closed by PS) 


Radius Ven. Spec. 
0x1 A 


Length 
OxOC 


Vendor ID 
0x0000 


Vendor ID (cent.) 
118B 


Type 
0x36 


Length 
0x06 


QoS Usage Info 
0x77777777 (bytes) 


Radius Ven. Spec. 
0x1 A 


Length 
OxOC 


Vendor ID 
0x0000 


Vendor ID (cent.) 
118B 


Type 
0x3F 


Length 
0x06 


QoS Time Info 
0x77777777 (seconds) 
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16a. After receiving and recording the QoS_Release Event Message, the RKS acknowledges the message. 







1 



Accou nting-Response Radius Header 



16b. After receiving the Gate-Delete- Ack from the CMTS, the Policy Server will send a Gate -Delete- Ack to 
complete the Gate-Control transaction. 







1 



COPS Header 



Version 
0x1 



Flags 
0x1 



Op-Code 
0x03 



Client-Type 
OxSOOA 



Message Length 
0x00000034 

Length 
0x0008 



COPS Handle Object 
C-Num 
0x01 



C-Type 
0x01 



Handle 
0x00001234 



COPS Report-Type Object 



Length 

0x0008 

Report Type (R-Type) 
0x0001 (Success) 



C-Num 

0x12 

Reserved 



C-Type 
0x01 



Length 
0x001 C 



COPS ClientSI Object Header 
I C-Num 
0x09 



C-Type 
0x01 



Multimedia TransactionID Object 



Length 
0x0008 
TransactionID 
0x9998 

Length 
0x0008 



S-Num 

0x01 

Gate Command 

OxOOOB (Gate-Delete-Ack) 

Multimedia AMID Object 

S-Num 
0x02 



S-Type 
0x01 



S-Type 
0x01 



AMID 
0x0000 



Application Manager Tag 

0x5678 

Multimedia GatelD Object 



Length 
0x0008 
GatelD 
0x12345678 



S-Num 
0x04 



S-Type 
0x01 



16c. The Policy Server sends a Policy_Delete Event Message to the RKS to complete the entire process. 
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1 



Accounting-Request _Radjus Header 



Radius Ven. Spec. 
0x1 A 



Length 
0x54 



Vendor ID 
0x0000 



Vendor 
118B 



D (cent.) 



Type 
0x01 



EM Header) 



Length 
0x4E 



Version 
0x0001 



BCID 
0x3E48 



BCID (cent.) 

1 208202020202031 3436302D3035303030300003DB77 



Event IViessage Type 
0x0016 (Policy_Delete) 



Element Type 
0x0004 (Policy Server) 



Element ID 
0x2020202035363738 



Time Zone 
0X302D303530303030 



Sequence Number 
0x0000 



Sequence Number (cent.] 
0002 



Event Time 
0x3230 



Event Time (cent.) 

303231 3230363030303030302E343030 



Status 
0x00000000 



Priority 
0x80 



Attribute Count 
0x0004 



Event Object 
0x00 



Radius Ven. Spec. 
0x1 A 



Length 
OxOC 



Vendor ID 
0x0000 



Vendor ID (cent.; 
118B 



Type 
0x3D 



Length 
0x06 



Application_IVIanager_ 
0x00005678 



ID 



Radius Ven. Spec. 
0x1 A 



Length 
OxOC 



Vendor ID 
0x0000 



Vendor ID (cent.; 
118B 



Type 
0x34 



Length 
0x06 



SubscriberlD 
0x01010101 



Radius Ven. Spec. 
0x1 A 



Length 
OxOA 



Vendor I 
0x0000 



Vendor ID (cent.; 
118B 



Type 
0x3A 



Length 
0x04 



Policy_Deleted_Reason 

0x0001 (Application IVIanager Request) 



Radius Ven. Spec. 
0x1 A 



Length 
0x1 C 



Vendor ID 
0x00001 18B 



Type 
0x31 



Length 
0x16 



FEID 
0x0000 



FEID (cent.) 

000000000000005061 636B65744361 626C65 
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17. After receiving and recording the Policy_Delete Event Message, the RKS acknowledges the message. 
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Annex A (informative): 

Guidelines for Version Number Assignment 

Interoperability between different protocol versions is based on the following principles: 

Robustness Principle: 

RFC 791 [i.6] defines the general "robustness principle" for the internet protocol as follows: 

• "An implementation should be conservative in its sending behavior and liberal in its receiving behavior". 

• Following such a robustness principle, it is possible to permit minor changes in the protocol while still 
maintaining backwards compatibility. 

The general rule for protocol version numbering within IPCablecom Multimedia Gate Control Protocol is as follows: 

• Protocol versions within the same major version number should be backwards compatible. Versions with 
different Major Version Number are not expected to be backwards compatible. 

It is crucial that the IPCablecom Multimedia Specification team examine all protocol changes to be included in a new 
version of the protocol and select a protocol version number based on the change with the largest impact. If any of the 
changes satisfy the criteria for a major protocol version change, then the major version should be incremented. 

Examples of protocol changes which would result in change to the minor version number: 

• The introduction of a new optional object so long as the inclusion of the new object in a message does not 
introduce new mandatory functional requirements on the network element receiving the message such that the 
object could be safely ignored. 

• The deprecation of an optional object. 

Examples of protocol changes which would result in a change to the major version number: 

• The introduction of a new message. 
A change in the format of a given object. 

A grammar change which prohibited the inclusion of a given object in a given message. 
A grammar change which made an object mandatory in a given message. 
A grammar change which made an object optional in a message in which it was previously mandatory. 



• 



• 



• 



The introduction of a new optional object which when included in a message introduces new mandatory 
functional requirements on the network element receiving the message such that the new object could not be 
safely ignored. 

A semantic change to the protocol related algorithms or states (such as the gate state machine) that could result 
in a state inconsistency between devices running the new and old protocol versions. 



Some changes, such as those which introduce new functionality, are difficult to classify. For example, one could 
imagine a change which introduced a new object and functional requirements on the network element receiving the 
object in a message. If the network element receiving the object was operating on a lower version of the protocol in 
which the new object was not defined, then the default behavior would be that the object would be ignored and 
consequently the behavior implied by the new object would not be performed. If the new behavior that is not performed 
due to the object being ignored was local to the receiving network element, one could argue that in this case, the two 
network elements are successfully interoperating at the lower version of the protocol. If, on the other hand, the presence 
of the new object in a message required the receiving network element to send a new response or to modify an existing 
response based on the new object, then to ignore the new object might prevent interoperability. In the latter case, a 
major version change would be required. 
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Other changes, such as those which change the status of an object within a message from mandatory to optional or vice 
versa could result in interoperable implementations based on the behavior of the sender. However, since the behavior of 
a sender with respect to optional parameters cannot be guaranteed, such changes should be classified a major changes. 

Given that many types of protocol changes would require a major protocol version change, it makes sense to group 
changes to the protocol such that major version changes occur infrequently and new versions provide significant value 
which justifies their implementation. 
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Annex B (informative): 
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